[Home]

Summary:ASTERISK-16262: Asterisk seg faults after incoming OOH323 call fails due to congesstion
Reporter:Vladimir Mikhelson (vmikhelson)Labels:
Date Opened:2010-06-17 21:48:27Date Closed:2011-06-07 14:00:30
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Addons/chan_ooh323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) segfault1.txt
Description:A call is placed to a SIP extension with no VoiceMail. If the call goes through there is no problem.

If the call gets congested Asterisk experiences the following in about 10 seconds after the call ends:
[root@pbx ~]# /usr/sbin/safe_asterisk: line 145: 24682 Segmentation fault  (core dumped) nice -n $PRIORITY ${ASTSBINDIR}/asterisk -f ${CLIARGS} ${ASTARGS} > /dev/${TTY} 2>&1 < /dev/${TTY}
Asterisk ended with exit status 139
Asterisk exited on signal 11.
Automatically restarting Asterisk.

The same SIP extension can be called from a SIP or a DAHDI extension with no adverse effects.

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

AsteriskNOW 1.7.0 with latest yum updates.

First experienced with FreePBX 2.7.  Upgraded to FreePBX 2.8 Beta2.  Results did not change.

Extension being called is a Sip2Sis Skype extension.  I do not believe it matters but just in case it does...

Call flow is identical for the DAHDI, SIP, and OOH323 calls.

"ooh323 set debug" did not reveal any clues.
Comments:By: Vladimir Mikhelson (vmikhelson) 2010-06-17 22:08:13

Uploaded "segfault1.txt" with a portion of a captured console screen output. The call was placed from the OOH323 extension 352 to the SIP extension 700.

"Disconnected from Asterisk server" indicates the Astrisk Server going down due to the segmentation fault.
By: Alexander Anikin (may213) 2010-06-20 13:10:54

Vladimir,

Are you try latest svn version of 1.6.2 addons? If no i think you can update to this and will have no problem.
Problem is like to 0017227 and there is patch to solve it.
By: Vladimir Mikhelson (vmikhelson) 2010-06-20 22:48:38

May213,

It worked as you expected.

Now a congested call finishes like that:

   -- Executing [s-CONGESTION@macro-exten-vm:3] PlayTones("OOH323/avaya-0a03a608", "congestion") in new stack
   -- Executing [s-CONGESTION@macro-exten-vm:4] Congestion("OOH323/avaya-0a03a608", "10") in new stack
 == Spawn extension (macro-exten-vm, s-CONGESTION, 4) exited non-zero on 'OOH323/avaya-0a03a608' in macro 'exten-vm'
 == Spawn extension (from-trunk, 700, 1) exited non-zero on 'OOH323/avaya-0a03a608'
   -- Executing [h@from-trunk:1] Macro("OOH323/avaya-0a03a608", "hangupcall,") in new stack
   -- Executing [s@macro-hangupcall:1] GotoIf("OOH323/avaya-0a03a608", "1?skiprg") in new stack
   -- Goto (macro-hangupcall,s,4)
   -- Executing [s@macro-hangupcall:4] GotoIf("OOH323/avaya-0a03a608", "1?skipblkvm") in new stack
   -- Goto (macro-hangupcall,s,7)
   -- Executing [s@macro-hangupcall:7] GotoIf("OOH323/avaya-0a03a608", "1?theend") in new stack
   -- Goto (macro-hangupcall,s,9)
   -- Executing [s@macro-hangupcall:9] Hangup("OOH323/avaya-0a03a608", "") in new stack
 == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'OOH323/avaya-0a03a608' in macro 'hangupcall'
 == Spawn extension (from-trunk, h, 1) exited non-zero on 'OOH323/avaya-0a03a608'

I think you can add a relationship to this issue and close it.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2010-06-21 09:10:24

closed because duplicate to 0017227.