Bug #1625
closedcoer dump from hammer info
Added by steve almost 15 years ago. Updated almost 15 years ago.
0%
Description
Hi,
I'm running v2.5.1.376.g8b72b-DEVELOPMENT with hammer version 4
filesystems (upgraded from version 1 original builds). When I run hammer
info I get a coredump as it starts on one of the filesystems (the other two
report OK). The message is:
assertion: z->z_Magic == ZALLOC_SLAB_MAGIC in _slabfree
Abort trap: 6 (core dumped)
It comes just after reporting on the mountpoints of one filesystem
and just before it would print "Volume identification" for the last
filesystem.
Core dump attached.
The filesystem seems to be working fine.
Files
hammer.core (380 KB) hammer.core | steve, 12/13/2009 09:22 AM |
Updated by dillon almost 15 years ago
: Hi,
:
: I'm running v2.5.1.376.g8b72b-DEVELOPMENT with hammer version 4
:filesystems (upgraded from version 1 original builds). When I run hammer
:info I get a coredump as it starts on one of the filesystems (the other two
:report OK). The message is:
:
:assertion: z->z_Magic == ZALLOC_SLAB_MAGIC in _slabfree
:Abort trap: 6 (core dumped)
:
: It comes just after reporting on the mountpoints of one filesystem
:and just before it would print "Volume identification" for the last
:filesystem.
:
: Core dump attached.
:
: The filesystem seems to be working fine.
The core dump doesn't help without the binary as well. But please
don't post such big files, the mailing lists aren't designed for it.
What you can do instead is recompile your hammer binary with
DEBUG_FLAGS=-g, get another core dump, and gdb it yourself.
su
cd /usr/src/sbin/hammer
make clean
make DEBUG_FLAGS=-g all install
(run hammer info such that it core dumps)
gdb /sbin/hammer hammer.core
gdb> back (get backtrace w/ gdb)
-Matt
Updated by steve almost 15 years ago
On Sun, 13 Dec 2009 17:03:51 -0800 (PST)
Matthew Dillon <dillon@apollo.backplane.com> wrote:
The core dump doesn't help without the binary as well. But please
don't post such big files, the mailing lists aren't designed for it.
Sorry.
What you can do instead is recompile your hammer binary with
DEBUG_FLAGS=-g, get another core dump, and gdb it yourself.
Done but the result is not too helpful, looks like the stack got
mangled.
Program terminated with signal 6, Aborted.
#0 0x0807528b in ?? ()
(gdb) back
#0 0x0807528b in ?? ()
#1 0x080708ab in ?? ()
...
Updated by alexh almost 15 years ago
Can you also recompile libraries such as libc and others that hammer utility
links to with DEBUG_FLAGS=-g and try again?
Cheers,
Alex Hornung
Updated by steve almost 15 years ago
On Mon, 14 Dec 2009 09:05:00 +0000
"Alex Hornung \(via DragonFly issue tracker\)"
<sinknull@leaf.dragonflybsd.org> wrote:
Alex Hornung <ahornung@gmail.com> added the comment:
Can you also recompile libraries such as libc and others that hammer
utility links to with DEBUG_FLAGS=-g and try again?
Recompiled libc, libm and libutil - same result.
Is there any kind of debugging mode for the slab allocator that
can be turned on ?
Updated by steve almost 15 years ago
On Mon, 14 Dec 2009 09:36:53 +0000
"Steve O'Hara-Smith" <steve@sohara.org> wrote:
On Mon, 14 Dec 2009 09:05:00 +0000
"Alex Hornung \(via DragonFly issue tracker\)"
<sinknull@leaf.dragonflybsd.org> wrote:Alex Hornung <ahornung@gmail.com> added the comment:
Can you also recompile libraries such as libc and others that hammer
utility links to with DEBUG_FLAGS=-g and try again?Recompiled libc, libm and libutil - same result.
Is there any kind of debugging mode for the slab allocator that
can be turned on ?
Finally got a decent backtrace out of it.
Program terminated with signal 6, Aborted.
#0 0x0807528b in kill ()
(gdb) bt
#0 0x0807528b in kill ()
#1 0x080708ab in raise ()
#2 0x08070276 in abort ()
#3 0x08059cd7 in _mpanic ()
#4 0x08059e7f in _slabfree ()
#5 0x08059f98 in free ()
#6 0x0805560b in show_info (path=0x28090a4c "/roots") at cmd_info.c:185
#7 0x08055696 in hammer_cmd_info () at cmd_info.c:61
#8 0x08048bf0 in main (ac=Cannot access memory at address 0x5
) at hammer.c:310
Which I think reveals the problem - line 185 of cmd_info.c is
free(mountedon) - mountedon (if set) is the path argument to show_info
which comes from the getmntinfo() call on line 51. According to man
getmntinfo the returned data is an array of statfs structures which
(according to man statfs) contain fixed sized arrays for the mount point
name not allocated pointers.
So in short I'm pretty sure mountedon should not be being freed,
commenting out the free on line 185 does make hammer info work for me.
Updated by dillon almost 15 years ago
: So in short I'm pretty sure mountedon should not be being freed,
:commenting out the free on line 185 does make hammer info work for me.
:
:--
:Steve O'Hara-Smith | Directable Mirror Arrays
Nice catch. It looks like the best solution is to strdup() the
passed path on line 167. Could you keep the free() and try that
instead?
-Matt
Matthew Dillon
<dillon@backplane.com>
diff --git a/sbin/hammer/cmd_info.c b/sbin/hammer/cmd_info.c
index bc93cb4..d4f14c6 100644
--- a/sbin/hammer/cmd_info.c
++ b/sbin/hammer/cmd_info.c@ -164,7 +164,7
@ show_info(char *path)
if (ioctl(fd, HAMMERIOC_GET_PSEUDOFS, &pfs) >= 0) {
ismaster = (pfs_od.mirror_flags & HAMMER_PFSD_SLAVE) ? 0 : 1;
if (pfs_id == 0)
- mountedon = path;
mountedon = strdup(path);
else
mountedon = find_pfs_mount(pfs_id, info.vol_fsid, ismaster);
Updated by steve almost 15 years ago
Hi Matt,
That's exactly what Antonio suggested (off list), I've just tried it
and it works a treat.
On Mon, 14 Dec 2009 08:07:01 -0800 (PST)
Matthew Dillon <dillon@apollo.backplane.com> wrote:
: So in short I'm pretty sure mountedon should not be being freed,
:commenting out the free on line 185 does make hammer info work for me.
:
:--
:Steve O'Hara-Smith | Directable Mirror ArraysNice catch. It looks like the best solution is to strdup() the
passed path on line 167. Could you keep the free() and try that
instead?-Matt
Matthew Dillon
<dillon@backplane.com>diff --git a/sbin/hammer/cmd_info.c b/sbin/hammer/cmd_info.c
index bc93cb4..d4f14c6 100644
--- a/sbin/hammer/cmd_info.c
++ b/sbin/hammer/cmd_info.c@ -164,7 +164,7
@ show_info(char *path)
if (ioctl(fd, HAMMERIOC_GET_PSEUDOFS, &pfs) >= 0) {
ismaster = (pfs_od.mirror_flags &
HAMMER_PFSD_SLAVE) ? 0 : 1; if (pfs_id == 0)
- mountedon = path;
mountedon = strdup(path);
else
mountedon = find_pfs_mount(pfs_id,
info.vol_fsid, ismaster);
Updated by ahuete.devel almost 15 years ago
Sorry, dunno why but I still keep clicking on "Reply" instead of
"Reply all" :-(
2009/12/14 Steve O'Hara-Smith <steve@sohara.org>:
Hi Matt,
That's exactly what Antonio suggested (off list), I've just tried it
and it works a treat.On Mon, 14 Dec 2009 08:07:01 -0800 (PST)
Matthew Dillon <dillon@apollo.backplane.com> wrote:: So in short I'm pretty sure mountedon should not be being freed,
:commenting out the free on line 185 does make hammer info work for me.
:
:--
:Steve O'Hara-Smith | Directable Mirror ArraysNice catch. It looks like the best solution is to strdup() the
passed path on line 167. Could you keep the free() and try that
instead?-Matt
Matthew Dillon
<dillon@backplane.com>diff --git a/sbin/hammer/cmd_info.c b/sbin/hammer/cmd_info.c
index bc93cb4..d4f14c6 100644
--- a/sbin/hammer/cmd_info.c
++ b/sbin/hammer/cmd_info.c@ -164,7 +164,7
@ show_info(char *path)
if (ioctl(fd, HAMMERIOC_GET_PSEUDOFS, &pfs) >= 0) {
ismaster = (pfs_od.mirror_flags &
HAMMER_PFSD_SLAVE) ? 0 : 1; if (pfs_id == 0)
- mountedon = path;
mountedon = strdup(path);
else
mountedon = find_pfs_mount(pfs_id,
info.vol_fsid, ismaster);--
Steve O'Hara-Smith | Directable Mirror Arrays
C:>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Updated by dillon almost 15 years ago
:Sorry, dunno why but I still keep clicking on "Reply" instead of
:"Reply all" :-(
Heh. I was wondering.
In anycase, its all fixed now.
-Matt