[Home]

Summary:ASTERISK-26306: channel: Hang-up crashes, chan_pjsip not cleaning up properly
Reporter:Alexander Traud (traud)Labels:
Date Opened:2016-08-19 05:49:31Date Closed:2016-09-07 02:52:54
Priority:CriticalRegression?
Status:Closed/CompleteComponents:Channels/chan_pjsip Core/Channels
Versions:11.23.0 13.10.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) A_private_data_hang-up.patch
( 1) B_private_data_hang-up.patch
Description:In the channel destructor, the private data structure of the underlying channel technology is freed to avoid a memory leak. However, some channel technologies use ast_calloc/malloc, some use reference counting via ao2_ref. The latter cause this crash, because ao2_ref(., -1) must be used with such a structure rather than ast_free(.). I have no idea how to fix this issue correctly and therefore cannot drive this issue any further.

*Step to Reproduce*
Put the following in your {{/etc/asterisk/extensions.conf}}, use {{chan_pjsip}} as channel technology and dial the extension ‘test’:
{noformat}exten => test,1,NoOp()
same => n,Set(CHANNEL(secure_bridge_media)=1)
same => n,Set(CHANNEL(secure_bridge_signaling)=1)
same => n,Dial(PJSIP/${EXTEN}&SIP/${EXTEN}){noformat}

*Expected Result*
Asterisk should call the endpoint 'test' via SIP over TLS (or SIP over Secure WebSockets) and use the RTP profile sAVP(F), to enable sRTP – regardless the settings in sip.conf or pjsip.conf.

*Actual Result*
Asterisk received signal SIGABRT and aborts:
{noformat}channel.c:6069 ast_request: Setting security requirements failed
channel.c:2223 ast_channel_destructor: Channel 'PJSIP/test-00000001' may not have been hung up properly
     __GI___libc_free at malloc.c:2969
ast_channel_destructor at channel.c:2224
     internal_ao2_ref at astobj2.c:445
            __ao2_ref at astobj2.c:516
  ast_channel_release at channel.c:1562
          ast_request at channel.c:6070
       dial_exec_full at app_dial.c:2426{noformat}

*Notes*
This issue has no real date when it came into Asterisk. When Reference Counting was introduced, more and more channel technologies/drivers went over to use that internally – but not all do, yet.
Comments:By: Alexander Traud (traud) 2016-08-19 05:51:28.478-0500

I attached two alternative patches which workaround the issue:
A) uses {{ao2_ref}} instead of {{ast_free}}; I am using just channel technologies which use Reference Counting.
B) does not do anything and creates a memory leak instead of a crash
Workarounds, neither is a solution for this issue.
By: Richard Mudgett (rmudgett) 2016-08-19 12:13:06.150-0500

In channel.c:ast_request() line 6097 instead of calling ast_channel_release() call ast_hangup() instead.  That should fix.

As you have found, it is also inappropriate for the ast_channel_destructor() to assume how to cleanup the channel tech's private structure.  The best that routine can do is give the warning and do nothing else about it.