Bug 320 - xfsinvutil -i crash with segfault
: xfsinvutil -i crash with segfault
Status: RESOLVED FIXED
Product: XFS
Classification: Unclassified
Component: xfsdump
: unspecified
: Linux
: normal
: ---
Assigned To: XFS power people
:
:
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-03-24 02:19 CST by Nicolas Kowalski
Modified: 2004-05-20 04:36 CDT (History)
0 users

See Also:


Attachments
initial xfsinvutil segv fix attempt (445 bytes, patch)
2004-03-24 13:56 CST, Nathan Scott
Details | Diff
xfsinvutil segv fix attempt#2 (430 bytes, patch)
2004-03-26 01:13 CST, Tim Shimmin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Kowalski 2004-03-24 02:19:10 CST
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 +++
Comment 1 Nathan Scott 2004-03-24 10:36:58 CST
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.
Comment 2 Nicolas Kowalski 2004-03-24 11:48:32 CST
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
Comment 3 Nathan Scott 2004-03-24 13:56:17 CST
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.
Comment 4 Nicolas Kowalski 2004-03-25 00:00:59 CST
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.
Comment 5 Nathan Scott 2004-03-25 17:43:50 CST
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.
Comment 6 Nicolas Kowalski 2004-03-26 00:14:44 CST
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

Comment 7 Tim Shimmin 2004-03-26 01:13:45 CST
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.
Comment 8 Tim Shimmin 2004-03-26 01:15:59 CST
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
Comment 9 Nicolas Kowalski 2004-03-26 01:54:11 CST
With this patch, it works ! :-)

Many thanks.
Comment 10 Christoph Hellwig 2004-05-20 02:36:08 CDT
The patch that fixed the bug has been in CVS for a while.