[Asterisk-Dev] -DO_CRASH

[SteveK]

On May 25, 2005, at 9:29 PM, Matthew Boehm wrote:

>> Matthew Boehm wrote:
>>
>>
>>> OK. So Asterisk has been crashed alot in the past 10 min. Like 5  
>>> or 6 times.
>>> Can't figure out wtf is going on.
>>>
>>> I keep seeing this right before crash:
>>>
>>> May 25 17:31:37 NOTICE[10570]: sched.c:290 ast_sched_del:  
>>> Attempted to
>>> delete nonexistent schedule entry 22!
>>>
>>> So I look at line 290, and it turns out that if I have -DDO_CRASH  
>>> enabled,
>>> asterisk will crash when it reaches that error.
>>>
>>> My question is why; why is that option there? Obviously the core  
>>> programmers
>>> would not have put that "optional crash" in there if it wasn't  
>>> important to
>>> know when an attempt to delete a nonexistent schedule entry occurs.
>>>
>>>
>>>
>>>
>> Because if you cause it to crash, you can get a core dump telling you
>> exactly what was trying to do that.
>>
>> It's basically the same behavior as assert()..
>>
>> I wouldn't think that trying to delete a non-existent scheduler entry
>> should be a fatal error on a production box though :)
>>
>
> That makes sense. Since my box "was" trying to delete non-existent  
> scheduler
> events, should I be worried? I saw in sched.c that there is a  
> function to
> print out what is stored in the scheduler but greping through the  
> whole
> asterisk source, there is no CLI option to call that function.

It would be good to know, at least,. what's calling the deletion..

There's some command-line option to enable this to, but if you do  
ulimit -c unlimited before you start asterisk, you'll get a core dump  
when it happens, then you can to thread apply all bt, and you'll see  
the culpable system.    Lots of things use schedulers -- the one I'd  
be most interested in (since my middle name is jitterbuffer,  
apparently), is the new iax2 jitterbuffer integration..

Either way, it could be a harmless bug, or could be indicative of  
something more serious.


-SteveK