Menu
▾
▴
#128 Segmentation Fault when using -A option
When restoring a very large multi-part dump using the -A <archive file> option, I get an immediate segmentation fault.
I've tried four different versions/builds of restore (including the current CVS version) and they all exhibit the problem.
I've not yet been able to reproduce the problem on anything except this one dump taken from a CentOS workstation, but at least it's consistent here...
> 5. Please provide detailed information about your system:
> distribution and its version (RedHat, Debian, Suse, homemade etc.)
Dump: CentOS 4, up-to-date on patches as of Sep 15 2008
Restore: CentOS 5, up-to-date on patches as of Sep 16 2008
> architecture (Intel, Sparc, PalmPilot etc.)
Intel x86 32 bit (Core 2)
> dump/restore version (0.4b13, etc)
dump (on CentOS 4):
+ dump-0.4b39-3 (RHEL patches applied)
restore (on CentOS 5):
+ dump-0.4b41-2 (RHEL patches applied)
+ dump-0.4b39-3 (RHEL patches applied)
+ dump-0.4b41 (unpatched)
+ dump from CVS Sep 16 2008 (unpatched)
> e2fsprogs version (1.17, etc)
e2fsprogs-1.39-15
> libc version (libc5, glibc2.0, gilbc2.1 etc)
glibc-2.5-24
> complete output of the dump/restore command which caused
> the failure (ok, you can delete the 'xx% done' lines)
> the device you dump into/restore from (tape drive, file etc).
Scenario 1: CentOS 5 stock restore
# /sbin/restore -i -M -D /home -A /backups/level0/lv_home.archive -f /backups/level0/lv_home.dump Segmentation fault (core dumped)
Scenario 2: CentOS 4 restore compiled on CentOS 5
# /usr/src/redhat/BUILD/dump-0.4b39/restore/restore -i -D /home -M -A VolGroup00_lv_home.archive -f VolGroup00_lv_home.dump
Scenario 3: Unpatched dump 0.4b41 from SourceForge
(built with ./configure --enable-debug)
# /home/swbonds/build/dump-0.4b41/restore/restore -i -D /home -M -A VolGroup00_lv_home.archive -f VolGroup00_lv_home.dump
reclen = 12, namlen = 1, type = 4
reclen = 12, namlen = 1, type = 4
reclen = 12, namlen = 2, type = 4
reclen = 12, namlen = 2, type = 4
reclen = 20, namlen = 10, type = 4
reclen = 20, namlen = 10, type = 4
reclen = 468, namlen = 7, type = 4
reclen = 468, namlen = 7, type = 4
Segmentation fault (core dumped)
Scenario 4: CVS version from Sep 16 2008
(built with ./configure --enable-debug)
# /home/swbonds/build/dump-cvs-20080916/restore/restore -i -D /home -M -A VolGroup00_lv_home.archive -f VolGroup00_lv_home.dump
reclen = 12, namlen = 1, type = 4
reclen = 12, namlen = 1, type = 4
reclen = 12, namlen = 2, type = 4
reclen = 12, namlen = 2, type = 4
reclen = 20, namlen = 10, type = 4
reclen = 20, namlen = 10, type = 4
reclen = 468, namlen = 7, type = 4
reclen = 468, namlen = 7, type = 4
Segmentation fault (core dumped)
> anything else you believe will help me to find the bug...
Scenario 1 backtrace (feeble)
# gdb /sbin/restore core.8176
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 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-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
(no debugging symbols found)
Core was generated by `restore -i -D /home -M -A VolGroup00_lv_home.archive
VolGroup00_lv_home.dump'.
Program terminated with signal 11, Segmentation fault.
#0 0x08051f43 in readxattr ()
(gdb) bt
#0 0x08051f43 in readxattr ()
#1 0x080497de in extractdirs ()
#2 0x0804cbc5 in main ()
Scenario 2 backtrace (better, but involves third-party code from RedHat):
# gdb /usr/src/redhat/BUILD/dump-0.4b39/restore/restore core.8188
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 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-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1".
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libext2fs.so.2...done.
Loaded symbols for /lib/libext2fs.so.2
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /lib/libe2p.so.2...done.
Loaded symbols for /lib/libe2p.so.2
Reading symbols from /usr/lib/libreadline.so.5...done.
Loaded symbols for /usr/lib/libreadline.so.5
Reading symbols from /usr/lib/libncurses.so.5...done.
Loaded symbols for /usr/lib/libncurses.so.5
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libbz2.so.1...done.
Loaded symbols for /usr/lib/libbz2.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `/usr/src/redhat/BUILD/dump-0.4b39/restore/restore -i -D /home -M -A VolGroup00_'.
Program terminated with signal 11, Segmentation fault.
#0 readxattr (buffer=0xbfba1df4 "\002") at tape.c:1233
1233 if (curfile.dip->di_size > XATTR_MAXSIZE) {
(gdb) bt
#0 readxattr (buffer=0xbfba1df4 "\002") at tape.c:1233
#1 0x0804b50e in extractdirs (genmode=1) at dirs.c:260
#2 0x0804e426 in main (argc=Cannot access memory at address 0x0
) at main.c:453
Scenario 3 backtrace: (It's all your code now...)
# gdb /home/swbonds/build/dump-0.4b41/restore/restore core.8198
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 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-redhat-linux-gnu"...Using host libthread_db lib
rary "/lib/libthread_db.so.1".
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libext2fs.so.2...done.
Loaded symbols for /lib/libext2fs.so.2
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /lib/libe2p.so.2...done.
Loaded symbols for /lib/libe2p.so.2
Reading symbols from /usr/lib/libreadline.so.5...done.
Loaded symbols for /usr/lib/libreadline.so.5
Reading symbols from /usr/lib/libncurses.so.5...done.
Loaded symbols for /usr/lib/libncurses.so.5
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libbz2.so.1...done.
Loaded symbols for /usr/lib/libbz2.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `/home/swbonds/build/dump-0.4b41/restore/restore -i -D /home -M -A VolGroup00_lv'.
Program terminated with signal 11, Segmentation fault.
#0 readxattr (buffer=0xbfff1694 "\002") at tape.c:1232
1232 if (curfile.dip->di_size > XATTR_MAXSIZE) {
(gdb) bt
#0 readxattr (buffer=0xbfff1694 "\002") at tape.c:1232
#1 0x0804b53e in extractdirs (genmode=1) at dirs.c:260
#2 0x0804e905 in main (argc=Cannot access memory at address 0x0
) at main.c:461
Scenario 4: (Most recent version I can get of your code)
# gdb /home/swbonds/build/dump-cvs-20080916/restore/restore core.9864
GNU gdb Red Hat Linux (6.5-37.el5_2.2rh)
Copyright (C) 2006 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-redhat-linux-gnu"...Using host libthread_db lib
rary "/lib/libthread_db.so.1".
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libext2fs.so.2...done.
Loaded symbols for /lib/libext2fs.so.2
Reading symbols from /lib/libcom_err.so.2...done.
Loaded symbols for /lib/libcom_err.so.2
Reading symbols from /lib/libe2p.so.2...done.
Loaded symbols for /lib/libe2p.so.2
Reading symbols from /usr/lib/libreadline.so.5...done.
Loaded symbols for /usr/lib/libreadline.so.5
Reading symbols from /usr/lib/libncurses.so.5...done.
Loaded symbols for /usr/lib/libncurses.so.5
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libbz2.so.1...done.
Loaded symbols for /usr/lib/libbz2.so.1
Reading symbols from /lib/libselinux.so.1...done.
Loaded symbols for /lib/libselinux.so.1
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libsepol.so.1...done.
Loaded symbols for /lib/libsepol.so.1
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Core was generated by `/home/swbonds/build/dump-cvs-20080916/restore/restore -i -D /home -M -A VolGrou'.
Program terminated with signal 11, Segmentation fault.
#0 readxattr (buffer=0xbfc0d324 "\002") at tape.c:1234
1234 if (curfile.dip->di_size > XATTR_MAXSIZE) {
(gdb) bt
#0 readxattr (buffer=0xbfc0d324 "\002") at tape.c:1234
#1 0x0804b67e in extractdirs (genmode=1) at dirs.c:260
#2 0x0804eac5 in main (argc=Cannot access memory at address 0x0
) at main.c:490
Although implied by the title, I forgot to mention that the simple workaround is to avoid using the "-A" option. When that's done, the dump restores fine, albeit rather slowly...