From takeda@takeda.tk  Tue Apr 27 14:44:26 2004
Return-Path: <takeda@takeda.tk>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 6B1C016A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 27 Apr 2004 14:44:26 -0700 (PDT)
Received: from freebsd.takeda.tk (node-402413e2.sna.onnet.us.uu.net [64.36.19.226])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A031D43D1D
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 27 Apr 2004 14:44:21 -0700 (PDT)
	(envelope-from takeda@takeda.tk)
Received: from freebsd.takeda.tk (takeda@localhost.takeda.tk [127.0.0.1])
	by freebsd.takeda.tk (8.12.9p2/8.12.9) with ESMTP id i3RLiKIp089469
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 27 Apr 2004 14:44:20 -0700 (PDT)
	(envelope-from takeda@takeda.tk)
Received: (from takeda@localhost)
	by freebsd.takeda.tk (8.12.9p2/8.12.9/Submit) id i3RLiJce089468;
	Tue, 27 Apr 2004 14:44:19 -0700 (PDT)
	(envelope-from takeda)
Message-Id: <200404272144.i3RLiJce089468@freebsd.takeda.tk>
Date: Tue, 27 Apr 2004 14:44:19 -0700 (PDT)
From: Dariusz Kulinski <takeda@takeda.tk>
Reply-To: Dariusz Kulinski <takeda@takeda.tk>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: restore crashes (reproducable, core file and backtrace log available)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         66036
>Category:       bin
>Synopsis:       restore crashes (reproducable, core file and backtrace log available)
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Apr 27 14:50:10 PDT 2004
>Closed-Date:    Fri May 23 19:35:53 UTC 2008
>Last-Modified:  Fri May 23 19:35:53 UTC 2008
>Originator:     Dariusz Kulinski
>Release:        FreeBSD 4.9-RELEASE-p4 i386
>Organization:
>Environment:
System: FreeBSD freebsd.takeda.tk 4.9-RELEASE-p4 FreeBSD 4.9-RELEASE-p4 #0: Wed Mar 17 22:05:17 PST 2004 root@freebsd.takeda.tk:/usr/obj/usr/src/sys/TUNED i386


	
>Description:
        I booted from 4.9-mini cd, then created slices I went to fixit menu, and went to shell
        ussing fixit floppy which I found on that CDROM.
        First two restores (level 0, and next incremental) were succesfuly, restore started crashing
        on third one. I went to my system, recompiled system restore utility, with DEBUG_FLAGS=-g
        it crashed too, but I got core files with debug symbols, here is result from bt:

root@freebsd:/root/crash# gdb restore -c rst.core
GNU gdb 4.18 (FreeBSD)
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs
Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf


warning: core file may not match specified executable file.
Core was generated by `rst'.
Program terminated with signal 11, Segmentation fault.
#0  myname (ep=0x85caa10) at /usr/src/sbin/restore/symtab.c:207
207             for (cp = &namebuf[MAXPATHLEN - 2]; cp > &namebuf[ep->e_namlen]; ) {
(gdb) bt
#0  myname (ep=0x85caa10) at /usr/src/sbin/restore/symtab.c:207
#1  0x804f632 in removeleaf (ep=0x85caa10) at /usr/src/sbin/restore/utilities.c:196
#2  0x804a084 in removeoldleaves () at /usr/src/sbin/restore/restore.c:194
#3  0x8048520 in main (argc=1, argv=0xbfbff7a0) at /usr/src/sbin/restore/main.c:213
(gdb) p ep->e_namlen
Cannot access memory at address 0x88441a0.
(gdb) p namebuf
$1 = '\000' <repeats 938 times>, "./usr/./usr/X./usr/doc/en_US.ISO8859-1/a../tm/ace+tao/files/patch-Scheduling_Service\000"
(gdb)

If you need more informations please let me know, I'll try to keep that core file on my HD.

This thing worrys me, because when system crashes looks like I won't be able to restore everything.

>How-To-Repeat:
   I can reproduce it each time, but I don't have idea how to produce dump output which
   would crash restore.
>Fix:

	


>Release-Note:
>Audit-Trail:

From: Dariusz Kulinski <takeda@takeda.tk>
To: freebsd-gnats-submit@FreeBSD.org, takeda@takeda.tk
Cc:  
Subject: Re: bin/66036: restore crashes (reproducable, core file and backtrace log available)
Date: Tue, 27 Apr 2004 22:00:24 -0700

 I was experimenting a little bit, looks like crash is while going down
 in directory hierarchy from:
 patch-Scheduling_Service, then files and then ace+tao, after ace+tao
 memory pointed by ep->e_parent is not accesible.
 
 I looked in google and located that file it's in
 /usr/ports/devel/ace+tao/files/patch-Scheduling_Service so it looks
 like somehow there is trace lost to that file.
 
 Before I was doing backup I set chflags nodump on some directories
 (one of them was /usr/ports), so I didn't expected /usr/ports to be
 backed up at all...
 
State-Changed-From-To: open->closed 
State-Changed-By: mckusick 
State-Changed-When: Fri May 23 19:35:04 UTC 2008 
State-Changed-Why:  
To: Derek Kulinski <takeda@chinatsu.takeda.tk> 
Subject: Re: FreeBSD bug report bin/66036: restore crashes  
-------- 
> Date: Fri, 23 May 2008 12:15:26 -0700 
> From: Derek Kulinski <takeda@chinatsu.takeda.tk> 
> To: Kirk McKusick <mckusick@mckusick.com> 
> Subject: Re: FreeBSD bug report bin/66036: restore crashes 
>  
> Hi Kirk, 
>  
> On Fri, May 23, 2008 at 11:47:55AM -0700, Kirk McKusick wrote: 
> > I am going through old FreeBSD bug reports trying to determine if 
> > they are still relevant. You filed "bin/66036: restore crashes" on 
> > Tue Apr 27 14:50:10 PDT 2004. There have been several patches to 
> > restore that may have fixed this problem. I am writing to find out 
> > if you have reason to believe that your reported bug is still present. 
> > If not, I will close the bug report. 
>  
> As far as I remember, the dump was generated on a live system 
> (FBSD 4.x doesn't have snapshots), so the dump file was a bit broken. 
>  
> Once I upgraded to 5.x+ I started using snapshots for the backup, 
> I don't think I experienced any situation like that since then. 
>  
> Though, I still think that restore shouldn't crash no matter what the 
> dump file contained... 
>  
> I guess there's no point in keeping the bug, though it seems 
> that dump/restore aren't really as robust as other FBSD tools, 
> which is a bit worrying since they're a bit important. 
>  
> Each time I do backup I run restore wirth -n option to check it, but 
> it still doesn't guarantee me that the backup will be 100% realiable. 
>  
> Derek 

Thanks for your report. I concur with you that restore should be as 
robust as possible which is what has lead me on my current crusade 
to track down all reported problems and try to ensure that they are 
resolved. The net effect is that restore is now more robust than it 
has been in the past, though I am sure that you can still find ways 
to choke it up. When all else fails, it can be run with -D (debugging) 
mode where it will do its best to keep going no matter what you feed it. 

Kirk McKusick 


http://www.freebsd.org/cgi/query-pr.cgi?pr=66036 
>Unformatted:
