Bug #4229
mdb hangs on exit when long umem cache names exist
Start date:
2013-10-18
Due date:
% Done:
100%
Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:
Description
libumem allows caches to have an ASCII name - up to 31 chars. If a 31-char long name is used, mdb will hang on exit. (A shorter cache name works as expected.)
$ <download attached test file> $ gcc -Wall -O1 -lumem -o test test.c $ ./test 30 making cache of length 30: 123456789012345678901234567890 Segmentation Fault (core dumped) $ echo '' | mdb core $ ./test 31 making cache of length 31: 1234567890123456789012345678901 Segmentation Fault (core dumped) $ echo '' | mdb core <hang>
The hang is mdb pegging a CPU looping inside the teardown code:
nv_hashstring+0x2c(81b2e9d, 8102c68, 8046828, 8074053) mdb_nv_lookup+0x10(8102c68, 81b2e9d, 81038b0, 81b09dd) mdb_module_remove_walker+0x1b(8102c50) mdb_module_unload_common+0x11e(81038b0, 8139f28, 80468c8, 809af3f, 0, 54) mdb_module_unload+0xe(81038b0, 2, 80468d8, 2) mdb_module_unload_all+0x20(2) mdb_destroy+0x3a(8103e98, 8139f10, 80476b8, 8083b76, 0, 8139f10) terminate+0x10(0, 8139f10, 80476b8, 8083ad9) main+0x14d2(2, 80476e8, 80476f4, 80476dc) _start+0x7d(2, 8047830, 8047834, 0, 804783e, 804784a)
Profiling stacks using DTrace shows that we're looping somewhere in:
mdb`mdb_module_unload+0xe mdb`mdb_module_unload_all+0x20 mdb`mdb_destroy+0x3a mdb`terminate+0x10 mdb`main+0x14d2 mdb`_start+0x7d
The culprit seems to be libumem:
$ sudo dtrace -n 'pid$target::mdb_module_unload:entry{ trace(copyinstr(arg0)) }' -p `pgrep mdb` dtrace: description 'pid$target::mdb_module_unload:entry' matched 1 probe CPU ID FUNCTION:NAME 0 77990 mdb_module_unload:entry ld.so.1 0 77990 mdb_module_unload:entry libc.so.1 0 77990 mdb_module_unload:entry libumem.so.1
Files