On Tue, Sep 15, 2009 at 05:50:24AM -0700, Valdemar Moreira Pavesi wrote: > > ::umem_status > Status: ready and active > Concurrency: 8 > Logs: transaction=128k (inactive) > Message buffer: > umem allocator: buffer modified after being freed > modification occurred at offset 0x48 (0xdeadbeefdeadbeef replaced by > 0xdeadbeefdead00ef) > buffer=73a6b00 bufctl=73a5380 cache: umem_alloc_224 > previous transaction on buffer 73a6b00: > thread=5 time=T-0.423608538 slab=73a3ed0 cache: umem_alloc_224 > libumem.so.1'umem_nofail_callback+0x120e > libumem.so.1'umem_cache_free+0x44 > libumem.so.1'umem_free+0xde > libumem.so.1'valloc+0x1d5 > libumem.so.1'free+0x15 > libsofia-sip-ua.so.0.2.0'sres_resolver_receive+0x1cd > DLP'_Z13do_sockeventsPvP6pollfdS_+0x66 > libsofia-sip-ua.so.0.2.0'su_timer_run+0xd97 > libsofia-sip-ua.so.0.2.0'su_port_getmsgs+0x2db > libsofia-sip-ua.so.0.2.0'su_clone_start+0x4f3 > libc.so.1'_thr_slot_offset+0x31b > libc.so.1'_thr_slot_offset+0x550 > umem: heap corruption detected > stack trace: > libumem.so.1'_PROCEDURE_LINKAGE_TABLE_+0x95e > libumem.so.1'vmem_heap_arena+0x7bd > libumem.so.1'umem_nofail_callback+0x103d > libumem.so.1'umem_cache_alloc+0xc8 > libumem.so.1'umem_alloc+0xaf > libumem.so.1'malloc+0x2e > libsofia-sip-ua.so.0.2.0'su_home_mutex_unlock+0x379 > libsofia-sip-ua.so.0.2.0'su_alloc+0x35 > libsofia-sip-ua.so.0.2.0'sres_resolver_new+0x12e > libsofia-sip-ua.so.0.2.0'sres_query+0xbb > DLP'_Z18sendEnumNAPTRQueryP14sres_context_s+0x2e6 > DLP'_Z18init_sender_threadPv+0x380 > libc.so.1'_thr_slot_offset+0x31b > libc.so.1'_thr_slot_offset+0x550 > > > 73a6b00$<bufctl_audit This should be 73a5380; 73a6b00 is the buffer address.
> > > $G > C++ symbol demangling enabled > > $C > fffffd7fec5fdad0 libc.so.1`strlen+0x40() > fffffd7fec5fdc30 libc.so.1`sprintf+0xcd() > fffffd7fec5fe050 libsig.so`sighdl_getpath+0x59() > fffffd7fec5fe490 libsig.so`sighdl_core+0x49() > fffffd7fec5fe4c0 libsig.so`sighdl_handler+0xb5() > fffffd7fec5fe4d0 libc.so.1`__sighndlr+6() > fffffd7fec5fe540 libc.so.1`call_user_handler+0x252() > fffffd7fec5fe570 libc.so.1`sigacthandler+0xde(6, 0, fffffd7fec5fe590) > fffffd7fec5fe980 libc.so.1`_lwp_kill+0xa() > fffffd7fec5fe9a0 libc.so.1`raise+0x19() > fffffd7fec5fe9b0 libumem.so.1`umem_do_abort+0x32() > fffffd7fec5feaa0 0xfffffd7fff3119f2() > fffffd7fec5feb20 libumem.so.1`umem_error+0x20d() > fffffd7fec5feb60 libumem.so.1`umem_cache_alloc_debug+0x18d() > fffffd7fec5feb90 libumem.so.1`umem_cache_alloc+0xc8() > fffffd7fec5febd0 libumem.so.1`umem_alloc+0xaf() > fffffd7fec5febf0 libumem.so.1`malloc+0x2e() > fffffd7fec5fec40 0xfffffd7ffe0d7c29() > fffffd7fec5fec60 libsofia-sip-ua.so.0.2.0`su_alloc+0x35() > fffffd7fec5fed00 0xfffffd7ffe0d2f1e() > fffffd7fec5fed50 libsofia-sip-ua.so.0.2.0`sres_query+0xbb() > fffffd7fec5fef20 sendEnumNAPTRQuery+0x2e6() > fffffd7fec5fefc0 init_sender_thread+0x380() > fffffd7fec5fefe0 libc.so.1`_thr_setup+0x5b() > fffffd7fec5feff0 libc.so.1`_lwp_start() Looks like whatever libsig.so is doing, it's sprintf()ing a bad string. But that's unrelated to the error, which is: > modification occurred at offset 0x48 (0xdeadbeefdeadbeef replaced by > 0xdeadbeefdead00ef) > buffer=73a6b00 bufctl=73a5380 cache: umem_alloc_224 The stack trace from the free you can get from "73a5380::bufctl -v". At the time this buffer was freed, umem overwrites the buffer with '0xdeadbeef', and at allocation time, we check to make sure the pattern is undisterbed. In this case, the byte at offset 0x49 has been cleared after the buffer was freed, which is a bug. If you want to see if there are any other freed-memory overwrites, you can do: ::umem_verify ! grep corrupt And for each line, take the cache address and do: addr::umem_verify To get the list of buffers; this one will be inluded. Cheers, - jonathan > > ::status > debugging core file of DLP (64-bit) from srx114 > file: /unisphere/srx3000/callp/bin/DLP > initial argv: DLP12 -l DLP12 -N 1 > threading model: multi-threaded > status: process terminated by SIGSEGV (Segmentation Fault) > > > > Message was edited by: valdemar > -- > This message posted from opensolaris.org > _______________________________________________ > mdb-discuss mailing list > mdb-discuss at opensolaris.org
