[Home]

Summary:ASTERISK-03511: [h323 only] segfault and deadlock when rtp starts immediatelly
Reporter:kot (kot)Labels:
Date Opened:2005-02-14 10:17:16.000-0600Date Closed:2008-01-15 15:30:26.000-0600
Priority:CriticalRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) h323_debug.txt
Description:when remote endpoint starts rtp channel immediatelly after making a call and
if asterisk try to hangup this call without delay, segmentation fault occured.
Also if asterisk try to indicate state busy without delay - deadlock occured.
I have chan_h323 CVS - Feb 14, 2005.



I have in my extension.conf:

  exten => 3600,1,Busy()

  exten => 3601,1,Hangup()

  exten => 3602,1,Wait(1)
  exten => 3602,2,Busy()

  exten => 3603,1,Wait(1)
  exten => 3603,2,Hangup(4)


I try to call from Definity PBX to Asterisk using Cisco AS5350 as H.323 Gateway.

 definity PBX ---(PRI)---> AS5350 ---(H.323)---> Asterisk


When I try to call asterisk extension via AS5350,
it starts rtp channels immediatelly after making a call (before called party taken offhook).

if I dial extension 3601 I have a segmentation fault.

h.323 debug: see attach h323_debug.txt

# gdb /usr/sbin/asterisk core.27619
#0  0xb64a9297 in setup_rtp_connection (call_reference=4481, remoteIp=0x8164f28 "\002", remotePort=18110,
   token=0x8163370 "ip$10.5.5.251:26082/4481", pt=135679784) at chan_h323.c:1281
1281            fmt = ast_best_codec(pvt->owner->nativeformats);
(gdb) bt
#0  0xb64a9297 in setup_rtp_connection (call_reference=4481, remoteIp=0x8164f28 "\002", remotePort=18110,
   token=0x8163370 "ip$10.5.5.251:26082/4481", pt=135679784) at chan_h323.c:1281
#1  0xb64b2d6c in MyH323_ExternalRTPChannel::Start (this=0x817c790) at ast_h323.cpp:943
#2  0xb5ed97eb in H323Connection::InternalEstablishedConnectionCheck ()
  from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
#3  0xb5ed9888 in H323Connection::OnSelectLogicalChannels ()
  from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
#4  0xb5ed69e5 in H323Connection::SendFastStartAcknowledge ()
  from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
ASTERISK-1  0xb5ed493b in H323Connection::AnsweringCall ()
  from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
ASTERISK-2  0xb5ed28e9 in H323Connection::OnReceivedSignalSetup ()
  from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
ASTERISK-3  0xb64b1488 in MyH323Connection::OnReceivedSignalSetup (this=0x8163390, setupPDU=@0xb31710c8) at ast_h323.cpp:687
ASTERISK-4  0xb5ed151c in H323Connection::HandleSignalPDU ()
  from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
ASTERISK-5  0xb5f1a28c in H323Transport::HandleFirstSignallingChannelPDU ()
  from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
ASTERISK-6 0xb5f16fc4 in H225TransportThread::Main () from /usr/src/openh323/openh323-v1_15_1/lib/libh323_linux_x86_r.so.1.15.1
ASTERISK-7 0xb63cc7be in PThread::PX_ThreadStart () from /usr/src/openh323/pwlib-v1_8_1/lib/libpt_linux_x86_r.so.1.8.1
ASTERISK-8 0xb75d2dfc in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-9 0xb74c7f2a in clone () from /lib/tls/libc.so.6

Looks like we have no pvt->owner when we call ast_best_codec in string
fmt = ast_best_codec(pvt->owner->nativeformats)

I tried to add following code before this string

       if (!pvt->owner) {
               ast_log(LOG_DEBUG, "PVT has no owner. no good!\n");
               return;
       }
It helps me, but I'm not quite sure it is correct.
Looks like oh323_hangup has already been called by Asterisk,
and pvt->owner has been destroyed by oh323_hangup,
but H.323 call is not cleared yet and OpenH323 starts
callback function setup_rtp_connection.

If I dial extension 3603 everything fine.


If I dial extension 3600 I have deadlock: when I hangup the calling party,
channel is not not destroying and CLI command "show channels" shows warning
"ast_channel_walk_locked: Avoided initial deadlock 'H323/...' 10 retries!"

I think, that's because when asterisk calls oh323_indicate it locks the pvt->owner->lock.
At that moment remote endpoint starts rtp channel and OpenH323 calls
MyH323_ExternalRTPChannel::Start. MyH323_ExternalRTPChannel::Start calls
setup_rtp_connection and this function try to call ast_set_read_format.
ast_set_read_format try to lock pvt->owner->lock, but it already locked by Asterisk (oh323_indicate), so this thread is waiting for unlock pvt->owner->lock.
At that time oh323_indicate calls h323_answering_call. h323_answering_call calls
endPoint->FindConnectionWithLock but it looks like connection is locked
by MyH323_ExternalRTPChannel::Start or something other (I'm not quite good in OpenH323). So this thread is waiting too.
and deadlock occured.

If I dial extension 3602 everything fine.
Comments:By: Olle Johansson (oej) 2005-03-17 08:00:07.000-0600

kot: Find JerJer on the IRC channel and see if you can get any help fixing this.
By: Clod Patry (junky) 2005-03-29 16:59:57.000-0600

Is there any development here?

/Housekeeping
By: Paul Cadach (pcadach) 2005-03-29 20:53:05.000-0600

I'm trying to resolve H.323 issues, so this bug could be covered too.
By: Paul Cadach (pcadach) 2005-03-31 13:28:42.000-0600

Looks like solution for this issue is found. The patch will be available shortly (this evening or tomorrow morning).
By: Paul Cadach (pcadach) 2005-04-01 14:12:35.000-0600

Try patch from ASTERISK-3758.
By: jerjer (jerjer) 2005-04-04 11:09:28

fixed in -head
By: jerjer (jerjer) 2005-04-04 11:09:44

not in -stable
By: Digium Subversion (svnbot) 2008-01-15 15:30:23.000-0600

Repository: asterisk
Revision: 5379

U   trunk/channels/h323/Makefile
U   trunk/channels/h323/ast_h323.cpp
U   trunk/channels/h323/ast_h323.h
U   trunk/channels/h323/chan_h323.h

------------------------------------------------------------------------
r5379 | jeremy | 2008-01-15 15:30:22 -0600 (Tue, 15 Jan 2008) | 2 lines

Better dependancy and version checking method, solve call problems when dealing with a gatekeeper, sanity check call cleanup, in hopes to avoid deadlocks (Bugs ASTERISK-3758 ASTERISK-3563, ASTERISK-3511)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5379
By: Digium Subversion (svnbot) 2008-01-15 15:30:26.000-0600

Repository: asterisk
Revision: 5383

U   trunk/channels/chan_h323.c

------------------------------------------------------------------------
r5383 | jeremy | 2008-01-15 15:30:26 -0600 (Tue, 15 Jan 2008) | 2 lines

Better dependancy and version checking method, solve call problems when dealing with a gatekeeper, sanity check call cleanup, in hopes to avoid deadlocks (Bugs ASTERISK-3758 ASTERISK-3563, ASTERISK-3511)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=5383