[sr-dev] [kamailio/kamailio] kamailio crashes on CANCEL due to empty reply_lumps (#872)

apogrebennyk notifications at github.com
Wed Nov 30 16:03:20 CET 2016


We have a crash in kamailio 4.4.4 after t_next_contacts() has been called from failure route, if at this very moment when kamailio is preparing new INVITE the caller sends a cancel.

#0 build_res_buf_from_sip_req (code=3186024432, code at entry=487, text=0x25, new_tag=0x7f8dcf5fb2b0 <tm_tag>, msg=0x7f8dbde6cf78,
returned_len=0xb7, bmark=0x4) at msg_translator.c:2395
#1 0x00007f8dcf35f7b2 in _reply (trans=0x7f8dbde70960, p_msg=0x7f8dbde6cf78, code=487, text=<optimized out>, lock=1) at t_reply.c:712
#2 0x00007f8dcf3b5e8b in e2e_cancel (cancel_msg=0x7f8dbde6dff0, cancel_msg at entry=0x7f8dd26bb750, t_cancel=0x25,
t_invite=0x7f8dbde70960) at t_fwd.c:1278 

So the scheme is the following: proxy > INVITE < 486 > INVITE* < CANCEL
Victor has investigated this and found that the issue seems to be related to the reply lumps added by append_to_reply when processing initial invite. In order to reproduce this you need children>=2. 

When first target replies 486 the proxy calls t_next_contacts() and starts preparing invite to the next target and at this time another process receives cancel and destroys the transaction, the process handling that invite message(*) gets crashed.

While we are investigating the possibility to move the append_to_reply calls to the branch route, would it be possible to avoid crash by some kind of lock mechanism? The thing is that it's not always possible to move append_to_reply to the branch route, e.g. our proxy is deployed behind stateless lb with multiple interfaces and proxy needs to tell lb which interface to use already in the 100 Trying reply it sends to lb as a first thing when receiving a message.


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/872
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20161130/1348bf99/attachment.html>


More information about the sr-dev mailing list