False alarm.
In case someone encounters something similar in the future:
I have a custom module that, in the on_tx callback, appends an attribute to the outgoing SDP (to combat some NAT64 network issues). I was creating an attribute from the transaction's pool, but placing the attribute on the SDP (which is owned by the invite session's pool). This meant that whenever the transaction's pool was destroyed, future attempts to clone the SDP would try to read the (now invalid) attribute from the old pool. They would get a random negative number out of the now-invalid memory, which caused PJSIP to try to allocate a negative amount of space to duplicate the string, which then blew up.
I've modified my on_tx callback to clone the SDP into the transaction's pool and append the attribute there (the attribute should only be added during the transaction, it doesn't need to live on the local SDP), which resolved the issue.
Best,
Colin
On Thu, Apr 27, 2017 at 10:27 PM, Colin Morelli <colin.morelli@xxxxxxxxx> wrote:
Worth noting we did not see the issue before, until we disabled UPDATE on out server which forces PJSIP to send a re-INVITE instead. So it at least seems to only happen when session timers are forced to use re-invites.It consistently crashes after the 2nd or 3rd attempt to refresh the session.On Thu, Apr 27, 2017 at 1:44 PM, Colin Morelli <colin.morelli@xxxxxxxxx> wrote:Using latest trunk, I'm seeing a crash in pjmedia_sdp_neg_send_local_offer when attempting to send a session refresh invite (the first session refresh works fine, the second crashes). It looks like a memory issue, as the crash is in pj_pool_create_block when attempting to duplicate the SDP.It seems like there's a small leak of some kind going on, as the memory usage does slowly increase over the course of the call (although to be fair I haven't isolated this as being PJSIP rather than my app), however even still the app is only using 46.2MB of memory on an iPhone 7 when this happens. I can't imagine the device is actually out of memory.Any thoughts?Colin
_______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@xxxxxxxxxxxxxxx http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
