assertion failed with v2.2.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm currently testing my pjsua2 binding (for node.js -- 'sipster' on npm)
and I am consistently getting an assertion failed when testing with pjsua2
acting as UAS and SIPp using the built-in UAC scenario.

The actual error is: node: ../src/pj/sock_common.c:309:
pj_sockaddr_get_addr: Assertion `a->addr.sa_family == PJ_AF_INET ||
a->addr.sa_family == PJ_AF_INET6' failed.

It appears that `a->addr.sa_family == 0`. What's happening when this occurs
is that I receive the INVITE from SIPp, 100 Trying is sent back, followed
by 200 OK (via answer()). SIPp then replies with an ACK and (multiple, due
to retransmission) BYE, but only occasionally will the binding will see the
ACK before the crash. The flow/code leading up to the crash
is: onCallMediaState() is called and within that callback I enqueue
appropriate event information and signal the main thread that there is an
event in the queue. Once in the event queue processing function in the main
thread, I do something like this:

        // `call` comes from the event information and is a Call instance
        CallInfo ci = call->getInfo();
        AudioMedia* media = NULL;
        for (unsigned i = 0, m = 0; i < ci.media.size(); ++i) {
          if (ci.media[i].type==PJMEDIA_TYPE_AUDIO
              && (media = static_cast<AudioMedia*>(call->getMedia(i)))) {
            // i == 0
            // ci.media[i].index == 0
            // ci.media[i].type == 1
            // ci.media[i].status == 1
            try {
              // getMedTransportInfo(i) is what fails ----v
              MediaTransportInfo mti = call->getMedTransportInfo(i);
            } catch (Error& err) {}
          }
        }

The backtrace from the core dump is:

#3  0x00007f2eff4ebdf2 in __GI___assert_fail (assertion=0x7f2efe081818
"a->addr.sa_family == PJ_AF_INET || a->addr.sa_family == PJ_AF_INET6",
file=0x7f2efe0817a0 "../src/pj/sock_common.c", line=309,
    function=0x7f2efe081aa0 <__PRETTY_FUNCTION__.6287>
"pj_sockaddr_get_addr") at assert.c:101
#4  0x00007f2efe077e4b in pj_sockaddr_get_addr () from
/usr/local/lib/libpj.so.2
#5  0x00007f2efe077fa2 in pj_sockaddr_print () from
/usr/local/lib/libpj.so.2
#6  0x00007f2eff0691e7 in
pj::MediaTransportInfo::fromPj(pjmedia_transport_info const&) () from
/usr/local/lib/libpjsua2.so.2
#7  0x00007f2eff06e443 in pj::Call::getMedTransportInfo(unsigned int) const
() from /usr/local/lib/libpjsua2.so.2

For pjsua2/pjsip the only non-default TransportConfig settings I'm using
are `boundAddress: '127.0.0.1'` and `port: 0` and the only non-default
AccountConfig setting I'm using is `idUri: 'sip:127.0.0.1'`.

// here 6060 is an example random port that pjsip ended up listening on
For SIPp, I'm using this command line (v3.4): sipp -nostdin -i 127.0.0.1
-mi 127.0.0.1 -timeout 3s -timeout_error -s sipster -ap sipster -sn uac -l
1 -n 1 127.0.0.1:6060



I'm not sure if this is a bug in pjsip or if there is something else I
should be checking with media objects to ensure they are really are still
valid. I should note that when I test manually with a GUI UAC or some other
SIP trunk, I do not have this problem, so it must be some sort of issue
related to timing. I can supply additional debug information if needed.

Any help would be greatly appreciated.

- Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20140414/d2c1d266/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux