[Home]

Summary:ASTERISK-08089: Frequent Crashes
Reporter:John Lange (johnlange)Labels:
Date Opened:2006-11-08 15:45:14.000-0600Date Closed:2006-11-15 11:36:13.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I'm afraid I don't have much detail as to what causes this. From our perspective it just crashes and I'm not aware of any particular thing that we are doing that causes it.

I have included 2 backtraces (I have many more). If more information is needed pleaes let me know and I'd be happy to provide it.



****** ADDITIONAL INFORMATION ******

SLES 10. Sangoma A104d.
Comments:By: jmls (jmls) 2006-11-08 15:52:09.000-0600

looks like you are running a macro (ivrmenu) when this crash happens. I would ask two things:

A) Could you check out the latest svn code for 1.4 and try to replicate the bug on that, as there have been a large number of bug fixes made since b3 was released

B) If A) still fails, please could you attach your dialplan so that we can see what is in the ivrmenu macro ?

Many thanks.
By: John Lange (johnlange) 2006-11-09 00:42:02.000-0600

Ok, I'm running 1.4svn version now and I have 2 new backtraces which seem to be unrelated to the previous 2 I uploaded. backtrace03 and backtrace04 crashed in different places in the dialplan however I think they both died at a do_monitor? I'm really not sure how to read the backtrace...
By: jmls (jmls) 2006-11-09 02:03:41.000-0600

are you doing anything special in the dialplan ? Or does it crash when you're making a call ? Inbound / outbound ? What type of phones do you have ? So many questions, so little time ;)
By: Jared Smith (jsmith) 2006-11-09 09:29:16.000-0600

I'd also check to see if you're calling macros from inside other macros -- I'm not sure this is the case (as I haven't seen your dialplan), but I've seen lots of instances where we break the stack because of the way nested macros work in Asterisk.

Just a suggestion... feel free to ignore it if isn't applicable.
By: John Lange (johnlange) 2006-11-09 09:37:18.000-0600

as per your questions in 8315. AFAIK we are not doing anything special in the dialplan. Voip devices are varied but mostly either linksys PAP2s or Linksys SPA942s.

Crashes seem random to me but its hard to tell. Doesn't the backtrace give some hints on that? Here are the last few lines of the console before the crash if that helps:

   -- Executing [7804445555@ecity_voipusers:1] Dial("SIP/2044332222x1-b7a13e38", "SIP/7804445555@remoteprovider") in new stack
   -- Called 7804445555@remoteprovider
   -- SIP/remoteprovider-082b7128 is making progress passing it to SIP/2044332222x1-b7a13e38
   -- SIP/remoteprovider-082b7128 answered SIP/2044332222x1-b7a13e38
   -- Packet2Packet bridging SIP/2044332222x1-b7a13e38 and SIP/remoteprovider-082b7128
 == Spawn extension (ecity_voipusers, 7804445555, 1) exited non-zero on 'SIP/2044332222x1-b7a13e38'
[Nov  8 21:07:10] NOTICE[26307]: chan_sip.c:14183 handle_request_register: Registration from '<sip:2049757121x2@192.168.5.9>' failed for '192.168.5.171' - No matching peer found
   -- Executing [4385354@ecity_voipusers:1] Goto("SIP/2044332222x1-b7a15460", "7804445555|1") in new stack
   -- Goto (ecity_voipusers,7804445555,1)
   -- Executing [7804445555@ecity_voipusers:1] Dial("SIP/2044332222x1-b7a15460", "SIP/7804445555@remoteprovider") in new stack
   -- Called 7804445555@remoteprovider
   -- SIP/remoteprovider-082b7128 is making progress passing it to SIP/2044332222x1-b7a15460
voip1*CLI>
Disconnected from Asterisk server
voip1:/usr/src/asterisk # /usr/sbin/safe_asterisk: line 111: 26282 Segmentation fault      (core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk ${CLIARGS} ${ASTARGS} >&/dev/${TTY} </dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
By: John Lange (johnlange) 2006-11-09 10:46:53.000-0600

Another backtrace from this morning.

The last 3 backtraces all have the following sequence at the end:

ast_io_wait
do_monitor
dummy_start
start_thread
clone

Is this significant?
By: John Lange (johnlange) 2006-11-10 10:55:12.000-0600

And another 3 backtraces. 7-9 all seem to die at the same place.

ASTERISK-6 0x080c1809 in __ast_pbx_run (c=0x81d3160) at pbx.c:2345
By: John Lange (johnlange) 2006-11-10 10:58:06.000-0600

And here is what the dial plan looks like at that point:

<deleted>


By: Jared Smith (jsmith) 2006-11-10 12:11:07.000-0600

Deleted all attachments at the request of wangster in #asterisk-dev
By: John Lange (johnlange) 2006-11-10 12:27:35.000-0600

I've narrowed this down considerably so this bug can be closed in favor of:

http://bugs.digium.com/view.php?id=8336
By: jmls (jmls) 2006-11-10 15:37:51.000-0600

closed at reporter's request