Hi, My asterisk segfaults a few times each day and the crash problem seems weird. When I run gdb on the core dump, it almost always segfaults on free() or malloc(). When I run the back trace, I see something weird. Here's one of the back traces. #0 0x4017f87f in _int_free () from /lib/libc.so.6 #1 0x4017e7f5 in free () from /lib/libc.so.6 #2 0x403be83e in __sip_destroy (p=0x8248c88, lockowner=1) at chan_sip.c:2278 #3 0x403b1728 in sip_destroy (p=0x49) at chan_sip.c:2366 #4 0x403bd18a in __sip_autodestruct (data=0x8248c88) at chan_sip.c:1370 #5 0x08056cda in ast_sched_runq (con=0x81940d8) at sched.c:373 #6 0x403c8a27 in do_monitor (data=0x0) at chan_sip.c:12201 #7 0x40021a62 in pthread_start_thread () from /lib/libpthread.so.0 #8 0x401e85ca in clone () from /lib/libc.so.6 In frame #4, sip_destroy() was called with the pointer address 0x8248c88. But in frame #3, the pointer address became 0x49. Then when it called __sip_destroy() in frame #2, the address became the original correct address (0x8248c88). If you look at the chan_sip.c code, there was nothing in the code that could have changed the pointer address. Any ideas on how it could have happened? I am using asterisk version 1.2.26. Thanks in advance, Steve
On Monday 02 March 2009 00:27:00 Steven J. Douglas wrote:> Hi, > > My asterisk segfaults a few times each day and the crash problem seems > weird. When I run gdb on the core dump, it almost always segfaults on > free() or malloc(). When I run the back trace, I see something weird. > Here's one of the back traces. > > #0 0x4017f87f in _int_free () from /lib/libc.so.6 > #1 0x4017e7f5 in free () from /lib/libc.so.6 > #2 0x403be83e in __sip_destroy (p=0x8248c88, lockowner=1) at > chan_sip.c:2278 > #3 0x403b1728 in sip_destroy (p=0x49) at chan_sip.c:2366 > #4 0x403bd18a in __sip_autodestruct (data=0x8248c88) at chan_sip.c:1370 > #5 0x08056cda in ast_sched_runq (con=0x81940d8) at sched.c:373 > #6 0x403c8a27 in do_monitor (data=0x0) at chan_sip.c:12201 > #7 0x40021a62 in pthread_start_thread () from /lib/libpthread.so.0 > #8 0x401e85ca in clone () from /lib/libc.so.6 > > In frame #4, sip_destroy() was called with the pointer address > 0x8248c88. But in frame #3, the pointer address became 0x49. Then when > it called __sip_destroy() in frame #2, the address became the original > correct address (0x8248c88). If you look at the chan_sip.c code, there > was nothing in the code that could have changed the pointer address. Any > ideas on how it could have happened? > > I am using asterisk version 1.2.26.Probably an optimization by the gcc compiler. Try 'make dont-optimize' and this other address will probably disappear. -- Tilghman