[asterisk-users] Weird segfault

[Steven J. Douglas]

Thanks! I'll give that a try.

Regards,
Steve.

Tilghman Lesher wrote:
> 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.
>
>