[asterisk-dev] 1.6.1: segfault ... error 6 - how to debug?

[sean darcy]

Mark Michelson wrote:
> sean darcy wrote:
>> I've been getting random crashes (every 3-5 days) with 1.6.1.6 when 
>> nothing is happening:
>>
>> Oct 17 09:21:52 asterisk kernel: asterisk[2880]: segfault at 0 ip 
>> 000000000043d269 sp 00007fcfb9219b60 error 6 in asterisk
>>   (deleted)[400000+170000]
>>
>> even though nothing is happening. This is a lightly loaded asterisk 
>> server, and there are no calls:
>>
>> [2009-10-17 09:09:53] NOTICE[28424] chan_sip.c: Peer 
>> 'proxy01.sipphone.com' is now Lagged. (2129ms / 2000ms)
>> [2009-10-17 09:10:04] NOTICE[28424] chan_sip.c: Peer 
>> 'proxy01.sipphone.com' is now Reachable. (1202ms / 2000ms)
>> [2009-10-17 18:38:11] NOTICE[3235] cdr.c: CDR simple logging enabled.
>>
>>
>> I've just grabbed today's svn and built it with DON'T OPTIMIZE and DEBUG 
>> THREADS. I assume this will get me a core dump in /tmp if there's 
>> another segfault. Is this what I need for a bug report?
>>
>> sean
> 
> Running Asterisk with the -g option is what will cause a core dump to be 
> generated during an abnormal exit. The location of the core dump is dependent 
> upon system settings. On my box, for example, the core is dumped to pwd. I'm 
> pretty sure that the safe_asterisk script specifically dumps the cores to /tmp 
> though.
> 
> DONT_OPTIMIZE is still important though because it means the backtrace obtained 
> from the core dump will be as accurate as possible and generally makes finding 
> the problem spot easier. DEBUG_THREADS is not so important when trying to debug 
> a crash. It's main use is for reporting errors when locks are misused and for 
> obtaining current information on the system when there is a deadlock.
> 
> Mark Michelson
> 

OK, got it. It segfault'ed again, but I hadn't changed the asterisk init 
to use -g. I have now. Let's see what happens on the next segfault.

sean