[Home]

Summary:ASTERISK-22897: WebSocket connection from JsSIP or SIPML5 generate a segmentation fault(core dumped)
Reporter:Max E. Reyes Vera J. (navaismo)Labels:
Date Opened:2013-11-22 13:02:22.000-0600Date Closed:2013-12-01 13:58:27.000-0600
Priority:MinorRegression?
Status:Closed/CompleteComponents:Resources/res_pjsip
Versions:12.0.0-beta1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Fedora 17, Linux version 3.8.11-100.fc17.x86_64Attachments:( 0) backtrace.txt
( 1) backtrace.txt
Description:Every time a websocket connection came from jssip or sipml5 asterisk crashes with the core dumped

Here is the output of the backtrace--->http://pastebin.com/48gRGM4f

Note: Asterisk was compiled with debugh_threads,better_backtraces and dont_optimize however there is the value <optimized out> in the backtrace.
Comments:By: Max E. Reyes Vera J. (navaismo) 2013-11-22 13:03:38.799-0600

Attaching backtrace.
By: Matt Jordan (mjordan) 2013-11-22 13:25:09.539-0600

I'm fairly sure that the code used by {{security_events}} is not going to work finding out whether or not a WS/WSS transport is in use:

{noformat}
static int find_transport_in_use(void *obj, void *arg, int flags)
{
struct ast_sip_transport *transport = obj;
pjsip_rx_data *rdata = arg;

if ((transport->state->transport == rdata->tp_info.transport) ||
(transport->state->factory && !pj_strcmp(&transport->state->factory->addr_name.host, &rdata->tp_info.transport->local_name.host) &&
transport->state->factory->addr_name.port == rdata->tp_info.transport->local_name.port)) {
return CMP_MATCH | CMP_STOP;
}

return 0;
}
{noformat}

Regardless, we shouldn't just dereference a NULL pointer. If the transport is unknown, it should just return "unknown".
By: Joshua C. Colp (jcolp) 2013-11-28 13:20:59.508-0600

A fix for this is now up for review at https://reviewboard.asterisk.org/r/3036/
By: Max E. Reyes Vera J. (navaismo) 2013-11-28 14:28:52.427-0600

Hi thanks Joshua, already patched with the provided code and its working fine until I execute the pjsip qualify <endpoint> it provoque a core dumped again, but I'm not sure if that apply as the same issue. Here is the cli output(I'm not attaching the new backtrace since I don't know if this is a "new issue" or not).

*CLI> pjsip qualify 5001
Sending qualify to endpoint 5001
contact sip:5001@10.0.1.102:36357;transport=ws;rtcweb-breaker=yes
<--- Transmitting SIP request (487 bytes) to WS:10.0.1.102:36357 --->
OPTIONS sip:5001@10.0.1.102:36357;transport=ws;rtcweb-breaker=yes SIP/2.0
Via: SIP/2.0/WS 10.0.1.102:36357;rport;branch=z9hG4bKPjb53060a6-e271-4bfa-a8de-e62286cf125f
From: <sip:4710dba4-729b-4d8a-b827-46719092cd99@Airo-Shaka>;tag=709ca5ad-c301-44f6-8575-34d6dc527ecf
To: <sip:5001@10.0.1.102;rtcweb-breaker=yes>
Contact: <sip:4710dba4-729b-4d8a-b827-46719092cd99@Airo-Shaka:5060;transport=WS>
Call-ID: 6d636ef6-f1bf-464e-9111-a5a869763082
CSeq: 1432 OPTIONS
Content-Length:  0


contact sip:vf9s9h5p@10.0.1.102:35493;transport=ws
[Nov 28 14:22:14] WARNING[8485]: pjsip:0 <?>: tsx0x7f7cc804c .Failed to send Request msg OPTIONS/cseq=23037 (tdta0x7f7cc8039a50)! err=171060 (Unsupported transport (PJSIP_EUNSUPTRANSPORT))
[Nov 28 14:22:14] ERROR[8485]: res_pjsip/pjsip_options.c:267 qualify_contact: Unable to send request to qualify contact sip:vf9s9h5p@10.0.1.102:35493;transport=ws
[Nov 28 14:22:14] ERROR[8485]: astobj2.c:166 INTERNAL_OBJ: bad magic number for object 0x7f7cc806ed70. Object is likely destroyed.
*CLI> asterisk: ../src/pj/os_core_unix.c:1287: pj_mutex_unlock: Assertion `mutex->owner == pj_thread_this()' failed.
Aborted (core dumped)

By: Max E. Reyes Vera J. (navaismo) 2013-11-28 14:59:27.138-0600

Now asterisk can't start with the following(note that transport and endpoints still the same, I haven't made changes to those values):

asterisk: ../src/pjsip/sip_transport.c:281: pjsip_transport_get_type_from_name: Assertion `!"Invalid transport name"' failed.
[Nov 28 14:54:37] NOTICE[9368]: res_pjsip/pjsip_distributor.c:246 log_unidentified_request: Request from '"test" <sip:5000@10.0.1.102>' failed for '10.0.1.110:5063' (callid: 1443846940@10.0.1.110) - No matching endpoint found
Aborted (core dumped)

Attaching second backtrace.
By: Joshua C. Colp (jcolp) 2013-11-28 15:10:51.154-0600

The qualify issues are a result of the OPTIONS code, unrelated to WebSocket. It just exposed it. I'll fix them. The second is also a result of the WebSocket code, so I'll fix that as well.
By: Joshua C. Colp (jcolp) 2013-11-28 15:17:00.217-0600

Review updated.
By: Max E. Reyes Vera J. (navaismo) 2013-12-02 18:26:28.426-0600

Thanks a lot.