Actions
Bug #5815
closedlibzpool's panic function doesn't set global panicstr, ::status not as useful
Start date:
2015-04-09
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:
Description
When panic() is called from within ztest, the mdb ::status command isn't as useful as it could be since the global panicstr variable isn't updated. We should modify the function to make sure panicstr is set, so ::status can present the error message just like it does on a failed assertion. For example, here's a core file suffering from this issue: $ mdb core.0 Loading modules: [ libumem.so.1 libc.so.1 libzpool.so.1 libcmdutils.so.1 libavl.so.1 libnvpair.so.1 ld.so.1 ] > ::status debugging core file of ztest (32-bit) from psurya-zloop.dcenter file: /net/galaxy/data/jenkins/zfs-make/psurya/38679-trunk/proto/root_i386/usr/bin/i86/ztest initial argv: /net/galaxy/data/jenkins/zfs-make/psurya/38679-trunk/proto/root_i386/usr/bin/i8 threading model: native threads status: process terminated by SIGABRT (Abort), pid=12306 uid=1138 code=-1 > ::stack libc.so.1`_lwp_kill+7(194, 6, f4830b48, fee2fea4, fef03000, 807bea0) libc.so.1`raise+0x22(6, 0, f4830b88, fee0d003) libc.so.1`abort+0xf3(807bea0, fed7c2f2, f4830bd4, fed58b74, fed95000, 10a) libzpool.so.1`panic(fed6b7cc, f4830bd4, 0, fed6b7cc) libzpool.so.1`panic+0x1f(fed6b7cc, 0, f4830bf8, fed04680, fffffffe, ffffffff) libzpool.so.1`metaslab_trace_add+0x63(c000244, 873e700, 8959140, 1000, 0, 0) libzpool.so.1`metaslab_group_alloc_holefill+0x12d(873e700, c000244, 1000, 0, 10a, 0) libzpool.so.1`metaslab_group_alloc+0x8b(873e700, c000244, 1000, 0, 10a, 0) libzpool.so.1`metaslab_alloc_dva+0x422(871a000, 8725900, 200, 0, 135cbc00, 0) libzpool.so.1`metaslab_alloc+0x2b6(871a000, 8725900, 200, 0, 135cbc00, 3) libzpool.so.1`zio_write_gang_block+0xd6(c000040, 1c, c000244, fed4c359) libzpool.so.1`zio_dva_allocate+0x32f(c000040, 0, 0, fed4c3a6) libzpool.so.1`zio_execute+0x1a2(c000040) libcmdutils.so.1`taskq_thread+0x1c6(8726f10, 0, 0, fee8f3a4) libc.so.1`_thrp_setup+0x8c(f8a10a40) libc.so.1`_lwp_start(f8a10a40, 0, 0, 0, 0, 0) > fed6b7cc/s 0xfed6b7cc: too many entries in allocation list > panicstr/s libc.so.1`panicstr: libc.so.1`panicstr: Prior to this patch, libzpool's vpanic() function rolled it's own mechanism for printing errors. Unfortunately, it wasn't properly setting libc's panicstr variable, which meant mdb's '::status' command wouldn't properly print the panic message. This patch removes the custom error handling/printing code in libzpool's vpanic() function, and uses assfail() instead. We couldn't use the generic Abort() function since it isn't exported, and modifying the interface of libc() is frowned upon. assfail() was slightly modified to better handle this case, since it would be awkward to print "assertion failed" when a panic() is triggered. Thus, when a NULL filename is used, the message is slightly tweaked to remove the reference to an assertion, and the filename and line number isn't printed (it doesn't make sense to feed in the filename and line number from vpanic() since it isn't a macro).
Updated by Gordon Ross about 7 years ago
Oh... nevermind. You're talking about explicit calls to panic().
The changes look fine. Sorry, it's been a long week... :-)
Updated by Electric Monk about 7 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit fae6347731c9d3f46b26338313b0422927f29cf6
commit fae6347731c9d3f46b26338313b0422927f29cf6 Author: Prakash Surya <prakash.surya@delphix.com> Date: 2015-05-16T18:53:51.000Z 5815 libzpool's panic function doesn't set global panicstr, ::status not as useful Reviewed by: Matthew Ahrens <mahrens@delphix.com> Reviewed by: Sebastien Roy <sebastien.roy@delphix.com> Reviewed by: Gordon Ross <gordon.ross@nexenta.com> Reviewed by: Rich Lowe <richlowe@richlowe.net> Approved by: Dan McDonald <danmcd@omniti.com>
Actions