On Fri, May 31, 2019, at 1:57 PM, Michael Maier wrote:
<snip>
>
> Thanks Joshua!
>
> I added the attached changes. Afterwards, I could see one SIGSEGV so
> far which I can't understand. I would be very happy, if you could take
> a
> look at it - maybe you have an idea? Most probably I'm doing something
> I shouldn't do (locking problem)?
>
> What I'm doing:
> In qualify_contact_cb, I'm checking for the status code of the received
> response. If the status code is 494, I'm again calling
> sip_options_qualify_contact() with the flag 494. In
> sip_options_qualify_contact, I'm checking for the flag == 494 to add
> the additional mediasec
> headers.
>
>
> Strangely, suddenly I could see one SIGSEGV (seems not (easily) to be
> reproducible) in
> qualify_contact_cb(void *token, pjsip_event e) at
>
> if (e->body.tsx_state.src.rdata->msg_info.msg->line.status.code == 494) {
>
> according core dump.
>
> The crash directly happened after a successful sequence of mediasec
> relevant endpoint (endpoint2):
>
> - request OPTIONS
> - response 494
> - request OPTIONS w/ MEDIASEC
> - response 200 OK
> - Crash
>
> Obviously, there has been a problem with the processing of the received
> 200 OK. But why?
You are assuming that the callback will always have a message. This isn't true.
The callback can occur if the request was sent and it received no response. The
switch statement handles this, specifically the PJSIP_EVENT_RX_MSG type, which
occurs if there is a response received.
--
Joshua C. Colp
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
