restore crashes

Dariusz Kulinski takeda at takeda.tk
Tue May 4 11:05:13 PDT 2004


Hello,

I booted from 4.9-mini cd, then created slices I went to fixit menu, and went to shell
using fixit floppy which I found on that CDROM.
First two restores (level 0, and next incremental) were successfully, 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 at 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.

I was also 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...

-- 
Best regards,
 Dariusz                          mailto:takeda at takeda.tk




More information about the freebsd-stable mailing list