Bugzilla – Bug 320
xfsinvutil -i crash with segfault
Last modified: 2004-05-20 04:36:08 CDT
The server is running Debian GNU/Linux 3.0, kernel 2.4.25 from the upstream. xfsdump (2.2.18) is compiled from the xfs-cmds CVS. "xfsdump -I" runs fine. "xfsinvutil -C" runs fine. "xfsinvutil -i" crashes with a segfault. Here is the output from strace: execve("/usr/sbin/xfsinvutil", ["xfsinvutil", "-i"], [/* 20 vars */]) = 0 uname({sys="Linux", node="gaspard", ...}) = 0 brk(0) = 0x8052bac open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=10278, ...}) = 0 old_mmap(NULL, 10278, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40014000 close(3) = 0 open("/lib/libuuid.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\v\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0644, st_size=8712, ...}) = 0 old_mmap(NULL, 11844, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40017000 mprotect(0x40019000, 3652, PROT_NONE) = 0 old_mmap(0x40019000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x40019000 close(3) = 0 open("/lib/libncurses.so.5", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\337\0"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0644, st_size=248132, ...}) = 0 old_mmap(NULL, 253056, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001a000 mprotect(0x4004f000, 35968, PROT_NONE) = 0 old_mmap(0x4004f000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x34000) = 0x4004f000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\30\222"..., 1024) = 1024 fstat64(3, {st_mode=S_IFREG|0755, st_size=1153784, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40058000 old_mmap(NULL, 1166560, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40059000 mprotect(0x4016c000, 40160, PROT_NONE) = 0 old_mmap(0x4016c000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x113000) = 0x4016c000 old_mmap(0x40172000, 15584, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40172000 close(3) = 0 munmap(0x40014000, 10278) = 0 stat64("/var/lib/xfsdump", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 stat64("/var/xfsdump", 0xbffffbcc) = -1 ENOENT (No such file or directory) brk(0) = 0x8052bac brk(0x8052be4) = 0x8052be4 brk(0x8053000) = 0x8053000 open("/var/lib/xfsdump/inventory/fstab", O_RDWR|O_LARGEFILE) = 3 flock(3, LOCK_EX) = 0 read(3, "\1\0\0\0\5\0\0\0\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0"..., 32) = 32 _llseek(3, 0, [0], SEEK_SET) = 0 mmap2(NULL, 2752, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x40014000 open("/var/lib/xfsdump/inventory/c184a2dc-6b9b-4d01-8181-c6fd34daa176.InvIndex", O_RDWR|O_LARGEFILE) = 4 flock(4, LOCK_EX) = 0 read(4, "\1\0\0\0\1\0\0\0\377\377\377\3771\3\0\0x6\1@\377\377\377"..., 32) = 32 _llseek(4, 0, [0], SEEK_SET) = 0 mmap2(NULL, 312, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0x40015000 brk(0x8054000) = 0x8054000 open("/var/lib/xfsdump/inventory/6514a9bc-4180-40d2-9f94-59c2d590b3b7.StObj", O_RDWR|O_LARGEFILE) = 5 flock(5, LOCK_EX) = 0 read(5, "\1\0\0\0\1\0\0\0\5\0\0\0\320\23\0\0\0\0\0\0A\200@\322\237"..., 32) = 32 _llseek(5, 0, [0], SEEK_SET) = 0 fstat64(5, {st_mode=S_IFREG|0644, st_size=5072, ...}) = 0 _llseek(5, 0, [0], SEEK_SET) = 0 mmap2(NULL, 5072, PROT_READ|PROT_WRITE, MAP_SHARED, 5, 0) = 0x40176000 open("/var/lib/xfsdump/inventory/1bb54683-d619-4bbc-ba16-be7e144229e1.InvIndex", O_RDWR|O_LARGEFILE) = 6 flock(6, LOCK_EX) = 0 read(6, "\1\0\0\0\1\0\0\0\377\377\377\3771\3\0\0x6\1@\377\377\377"..., 32) = 32 _llseek(6, 0, [0], SEEK_SET) = 0 mmap2(NULL, 312, PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x40016000 open("/var/lib/xfsdump/inventory/4197c50d-45a6-45de-9992-5a35c8c45d96.StObj", O_RDWR|O_LARGEFILE) = 7 flock(7, LOCK_EX) = 0 read(7, "\1\0\0\0\2\0\0\0\5\0\0\0x\26\0\0\0\0\0\0E\246E\336\231"..., 32) = 32 _llseek(7, 0, [0], SEEK_SET) = 0 fstat64(7, {st_mode=S_IFREG|0644, st_size=5752, ...}) = 0 _llseek(7, 0, [0], SEEK_SET) = 0 mmap2(NULL, 5752, PROT_READ|PROT_WRITE, MAP_SHARED, 7, 0) = 0x40178000 open("/var/lib/xfsdump/inventory/2daca37d-1c0a-4958-984b-d63f735bdef0.InvIndex", O_RDWR|O_LARGEFILE) = 8 flock(8, LOCK_EX) = 0 read(8, "\1\0\0\0\1\0\0\0\377\377\377\3771\3\0\0x6\1@\377\377\377"..., 32) = 32 _llseek(8, 0, [0], SEEK_SET) = 0 mmap2(NULL, 312, PROT_READ|PROT_WRITE, MAP_SHARED, 8, 0) = 0x4017a000 open("/var/lib/xfsdump/inventory/07a89215-d9d3-4023-96a1-e0775170cf30.StObj", O_RDWR|O_LARGEFILE) = 9 flock(9, LOCK_EX) = 0 read(9, "\1\0\0\0\2\0\0\0\5\0\0\0\270\23\0\0\0\0\0\0\331\323@#\226"..., 32) = 32 _llseek(9, 0, [0], SEEK_SET) = 0 fstat64(9, {st_mode=S_IFREG|0644, st_size=5048, ...}) = 0 _llseek(9, 0, [0], SEEK_SET) = 0 mmap2(NULL, 5048, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x4017b000 --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++
Could you provide a gdb backtrace please? (either run the command inside gdb till it dumps core, then "bt", else run 'gdb xfs_invutil core' and do the "bt" - provided you have a core file that is). thanks.
Here is the gdb backtrace: gaspard:~# xfsinvutil -i Segmentation fault (core dumped) gaspard:~# gdb /usr/sbin/xfsinvutil core GNU gdb 2002-04-01-cvs Copyright 2002 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-linux"... Core was generated by `xfsinvutil -i'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c79ef in malloc () from /lib/libc.so.6 (gdb) bt #0 0x400c79ef in malloc () from /lib/libc.so.6 #1 0x400c7074 in malloc () from /lib/libc.so.6 #2 0x0804e874 in node_create (hidden=1, expanded=0, level=4, deleted=0, file_idx=1, text=0x8054fb8 ' ' <repeats 12 times>, "media file: dlt4000", ops=0x8053320, parent=0x8054f60, children=0x0, nbr_children=0, data_idx=5) at list.c:68 #3 0x0804fdbf in generate_stobj_menu (startnode=0x8054b90, level=2, StObjFileName=0x8054bf8 "/var/lib/xfsdump/inventory/4197c50d-45a6-45de-9992-5a35c8c45d96.StObj") at stobj.c:505 #4 0x0804e322 in generate_invidx_menu (inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x80541e0, level=1, idxFileName=0x8053f38 "/var/lib/xfsdump/inventory/1bb54683-d619-4bbc-ba16-be7e144229e1.InvIndex") at invidx.c:973 #5 0x0804c1f5 in generate_fstab_menu (inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x0, level=0, fstabname=0x8053d18 "/var/lib/xfsdump/inventory/fstab") at fstab.c:283 #6 0x0804b9e3 in generate_menu (inv_path=0x8053640 "/var/lib/xfsdump/inventory") at cmenu.c:532 #7 0x0804bb1e in invutil_interactive (inv_path=0x8053640 "/var/lib/xfsdump/inventory", mountpt=0x0, uuidp=0x0, timeSecs=0) at cmenu.c:587 #8 0x08049b5d in main (argc=2, argv=0xbffffd84) at invutil.c:216
Created attachment 112 [details] initial xfsinvutil segv fix attempt That is pretty bizarre, not too much that looks like it could SEGV at that point, maybe your compiler is doing something wacko - does this patch help? thanks.
Unfortunately, the patch did not help. Here is the gdb backtrace I get this morning: gaspard:~# gdb xfsinvutil core GNU gdb 2002-04-01-cvs Copyright 2002 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-linux"... Core was generated by `xfsinvutil -i'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libuuid.so.1...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 0x400c79ef in malloc () from /lib/libc.so.6 (gdb) bt #0 0x400c79ef in malloc () from /lib/libc.so.6 #1 0x400c7074 in malloc () from /lib/libc.so.6 #2 0x0804e874 in node_create (hidden=1, expanded=0, level=4, deleted=0, file_idx=1, text=0x8054fc0 ' ' <repeats 12 times>, "media file: dlt7000", ops=0x8053320, parent=0x8054f68, children=0x0, nbr_children=0, data_idx=2) at list.c:68 #3 0x0804fdbf in generate_stobj_menu (startnode=0x8054218, level=2, StObjFileName=0x8054dd0 "/var/lib/xfsdump/inventory/4197c50d-45a6-45de-9992- 5a35c8c45d96.StObj") at stobj.c:505 #4 0x0804e322 in generate_invidx_menu ( inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x8054b38, level=1, idxFileName=0x8053f38 "/var/lib/xfsdump/inventory/1bb54683-d619-4bbc-ba16-be 7e144229e1.InvIndex") at invidx.c:973 #5 0x0804c1f5 in generate_fstab_menu ( inv_path=0x8053640 "/var/lib/xfsdump/inventory", startnode=0x0, level=0, fstabname=0x8053d18 "/var/lib/xfsdump/inventory/fstab") at fstab.c:283 #6 0x0804b9e3 in generate_menu ( inv_path=0x8053640 "/var/lib/xfsdump/inventory") at cmenu.c:532 #7 0x0804bb1e in invutil_interactive ( inv_path=0x8053640 "/var/lib/xfsdump/inventory", mountpt=0x0, uuidp=0x0, timeSecs=0) at cmenu.c:587 #8 0x08049b5d in main (argc=2, argv=0xbffffd54) at invutil.c:216 Thanks.
I would have been surprised if that was it, but worth checking (thanks). So, it looks like something is stomping on the libc malloc data structures causing libc to segfault. Possibly a use-after-free, or freeing unalloc'd memory, I would guess. Could you try linking with Electric Fence and then running that on the binary? You can set the environment variable MALLOCLIB to /usr/lib/libefence.a, then do "make distclean && make" in xfsdump - you should still see a segv, but hopefully at the point of failure now, not at some point afterward. Also, could you tar+gz up the contents of your /var/lib/xfsdump directory and send that to me please? thanks.
After tweaking the Makefile to make xfsinvutil build with electric-fence (-lpthread was missing to the linker), here is a gdb backtrace: # gdb /usr/sbin/xfsinvutil GNU gdb 2002-04-01-cvs Copyright 2002 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-linux"... (gdb) set args -i (gdb) r Starting program: /usr/sbin/xfsinvutil -i [New Thread 1024 (LWP 2423)] Electric Fence 2.1 Copyright (C) 1987-1998 Bruce Perens. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2423)] 0x400e1d85 in mempcpy () from /lib/libc.so.6 (gdb) bt #0 0x400e1d85 in mempcpy () from /lib/libc.so.6 #1 0x400d8488 in _IO_default_xsputn () from /lib/libc.so.6 #2 0x400b90eb in vfprintf () from /lib/libc.so.6 #3 0x400d00c3 in vsprintf () from /lib/libc.so.6 #4 0x400c040d in sprintf () from /lib/libc.so.6 #5 0x080500dc in generate_stobj_menu (startnode=0x401a1ff4, level=2, StObjFileName=0x401a9fb8 "/var/lib/xfsdump/inventory/6514a9bc-4180-40d2-9f94-59c2d590b3b7.StObj") at stobj.c:437 #6 0x0804e8b2 in generate_invidx_menu ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory", startnode=0x40193ff4, level=1, idxFileName=0x40199fb4 "/var/lib/xfsdump/inventory/c184a2dc-6b9b-4d01-8181-c6fd34daa176.InvIndex") at invidx.c:973 #7 0x0804c785 in generate_fstab_menu ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory", startnode=0x0, level=0, fstabname=0x4018bfdc "/var/lib/xfsdump/inventory/fstab") at fstab.c:283 #8 0x0804bf73 in generate_menu ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory") at cmenu.c:532 #9 0x0804c0ae in invutil_interactive ( inv_path=0x80545a0 "/var/lib/xfsdump/inventory", mountpt=0x0, uuidp=0x0, timeSecs=0) at cmenu.c:587 #10 0x0804a0ed in main (argc=2, argv=0xbffffd34) at invutil.c:216
Created attachment 114 [details] xfsinvutil segv fix attempt#2 Looks like xfsdump/invutil/stobj.c on line 432 may be not allocating a big enough txt string. It would be nicer to use snprintf() here and perhaps use a string length which is more accurate based on the length of session->session->s_label and a macro constant for the rest of the string.....but for now keep it simple.
Looks like xfsdump/invutil/stobj.c on line 432 may be not allocating a big enough txt string. It would be nicer to use snprintf() here and perhaps use a string length which is more accurate based on the length of session->session->s_label and a macro constant for the rest of the string.....but for now can you just try making 432 txt = malloc(60); to something bigger, say: 432 txt = malloc(60+strlen(session->session->s_label)); and see if that helps. I've attached patch.....I'm new to bugzilla... --Tim
With this patch, it works ! :-) Many thanks.
The patch that fixed the bug has been in CVS for a while.