Hello,
can you run list command in gdb to see the code? Because I am not sure what is exactly at that line in your version with the patch.
Cheers, Daniel
On 09.11.17 18:10, Marco Capetta wrote:
I applied the patch but kamailio crashes with the following error:
(gdb) bt full #0 0x00007f8af1e9b9ae in relay_reply (t=t@entry=0x7f8a29c05868, p_msg=p_msg@entry=0xffffffffffffffff, branch=branch@entry=0, msg_status=<optimized out>, cancel_data=cancel_data@entry=0x7ffd92443570, do_put_on_wait=do_put_on_wait@entry=0) at t_reply.c:1968 relay = 0 [...]
Hi Daniel,
due to other internal patches, the line number are a bit different. The issue seems located at the point where the patch was applied:
--- a/modules/tm/t_reply.c +++ b/modules/tm/t_reply.c @@ -1965,8 +1965,10 @@ enum rps relay_reply( struct cell *t, st if (SEND_PR_BUFFER( uas_rb, buf, res_len ) >= 0){ if (unlikely(!totag_retr && has_tran_tmcbs(t, TMCB_RESPONSE_OUT))){ LOCK_REPLIES( t ); - run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request, - relayed_msg, relayed_code); + if(relayed_msg->REPLY_STATUS==uas_rb->activ_type) { + run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request, + relayed_msg, relayed_code); + } UNLOCK_REPLIES( t ); } if (unlikely(has_tran_tmcbs(t, TMCB_RESPONSE_SENT))){
Thanks Marco
On 11/10/2017 08:41 AM, Daniel-Constantin Mierla wrote:
Hello,
can you run list command in gdb to see the code? Because I am not sure what is exactly at that line in your version with the patch.
Cheers, Daniel
On 09.11.17 18:10, Marco Capetta wrote:
I applied the patch but kamailio crashes with the following error:
(gdb) bt full #0 0x00007f8af1e9b9ae in relay_reply (t=t@entry=0x7f8a29c05868, p_msg=p_msg@entry=0xffffffffffffffff, branch=branch@entry=0, msg_status=<optimized out>, cancel_data=cancel_data@entry=0x7ffd92443570, do_put_on_wait=do_put_on_wait@entry=0) at t_reply.c:1968 relay = 0 [...]
-- Daniel-Constantin Mierla www.twitter.com/miconda --www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 13-15, 2017, in Berlin -www.asipto.com Kamailio World Conference -www.kamailioworld.com
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
On 11/10/2017 09:34 AM, Marco Capetta wrote:
+ if(relayed_msg->REPLY_STATUS==uas_rb->activ_type) { + run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request, + relayed_msg, relayed_code); + }
my guess is that in case of fake reply like a 408 the relayed_msg is -1 so addressing the member by pointer fails.
I have suggested Marco to try with if(relayed_msg==FAKED_REPLY || relayed_msg->REPLY_STATUS==uas_rb->activ_type)
Not sure if there are any other cases where relayed_msg is a NULL but we will test this and let you know if it helps.
Andrew
On 10.11.17 09:42, Andrew Pogrebennyk wrote:
On 11/10/2017 09:34 AM, Marco Capetta wrote:
+ if(relayed_msg->REPLY_STATUS==uas_rb->activ_type) { + run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request, + relayed_msg, relayed_code); + }
my guess is that in case of fake reply like a 408 the relayed_msg is -1 so addressing the member by pointer fails.
I have suggested Marco to try with if(relayed_msg==FAKED_REPLY || relayed_msg->REPLY_STATUS==uas_rb->activ_type)
Not sure if there are any other cases where relayed_msg is a NULL but we will test this and let you know if it helps.
Indeed, I noticed that is the FAKED_REPLY looking at the locals in the backtrace he sent to me. I think it is better to use relayed_code instead of relayed_msg->REPLY_STATUS in that condition.
Cheers, Daniel
Hi Daniel,
we left the test system running the whole weekend and so far we haven't see any new ACC record for provisional response messages. I think that the latest patch solved the issue.
Thank you
Cheers Marco
----- Original Message ----- From: "Daniel-Constantin Mierla" miconda@gmail.com To: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org, "Andrew Pogrebennyk" apogrebennyk@sipwise.com Sent: Friday, November 10, 2017 9:48:29 AM Subject: Re: [SR-Users] 183 acc records even if early_media equals to 0
On 10.11.17 09:42, Andrew Pogrebennyk wrote:
On 11/10/2017 09:34 AM, Marco Capetta wrote:
+ if(relayed_msg->REPLY_STATUS==uas_rb->activ_type) { + run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request, + relayed_msg, relayed_code); + }
my guess is that in case of fake reply like a 408 the relayed_msg is -1 so addressing the member by pointer fails.
I have suggested Marco to try with if(relayed_msg==FAKED_REPLY || relayed_msg->REPLY_STATUS==uas_rb->activ_type)
Not sure if there are any other cases where relayed_msg is a NULL but we will test this and let you know if it helps.
Indeed, I noticed that is the FAKED_REPLY looking at the locals in the backtrace he sent to me. I think it is better to use relayed_code instead of relayed_msg->REPLY_STATUS in that condition.
Cheers, Daniel
Hello,
ok, thanks for testing, good to know the issue was identified! I will do another review soon to see if there would be a better fix for the case.
Cheers, Daniel
On 13.11.17 09:46, Marco Capetta wrote:
Hi Daniel,
we left the test system running the whole weekend and so far we haven't see any new ACC record for provisional response messages. I think that the latest patch solved the issue.
Thank you
Cheers Marco
----- Original Message ----- From: "Daniel-Constantin Mierla" miconda@gmail.com To: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org, "Andrew Pogrebennyk" apogrebennyk@sipwise.com Sent: Friday, November 10, 2017 9:48:29 AM Subject: Re: [SR-Users] 183 acc records even if early_media equals to 0
On 10.11.17 09:42, Andrew Pogrebennyk wrote:
On 11/10/2017 09:34 AM, Marco Capetta wrote:
+ if(relayed_msg->REPLY_STATUS==uas_rb->activ_type) { + run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request, + relayed_msg, relayed_code); + }
my guess is that in case of fake reply like a 408 the relayed_msg is -1 so addressing the member by pointer fails.
I have suggested Marco to try with if(relayed_msg==FAKED_REPLY || relayed_msg->REPLY_STATUS==uas_rb->activ_type)
Not sure if there are any other cases where relayed_msg is a NULL but we will test this and let you know if it helps.
Indeed, I noticed that is the FAKED_REPLY looking at the locals in the backtrace he sent to me. I think it is better to use relayed_code instead of relayed_msg->REPLY_STATUS in that condition.
Cheers, Daniel
Hi Daniel,
did you have time to review the fix, or can I use the last suggested patch?
Thanks!
Cheers, Marco
On 11/14/2017 08:39 AM, Daniel-Constantin Mierla wrote:
Hello,
ok, thanks for testing, good to know the issue was identified! I will do another review soon to see if there would be a better fix for the case.
Cheers, Daniel
On 13.11.17 09:46, Marco Capetta wrote:
Hi Daniel,
we left the test system running the whole weekend and so far we haven't see any new ACC record for provisional response messages. I think that the latest patch solved the issue.
Thank you
Cheers Marco
----- Original Message ----- From: "Daniel-Constantin Mierla" miconda@gmail.com To: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org, "Andrew Pogrebennyk" apogrebennyk@sipwise.com Sent: Friday, November 10, 2017 9:48:29 AM Subject: Re: [SR-Users] 183 acc records even if early_media equals to 0
On 10.11.17 09:42, Andrew Pogrebennyk wrote:
On 11/10/2017 09:34 AM, Marco Capetta wrote:
if(relayed_msg->REPLY_STATUS==uas_rb->activ_type) {
run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request,
relayed_msg, relayed_code); + }
my guess is that in case of fake reply like a 408 the relayed_msg is -1 so addressing the member by pointer fails.
I have suggested Marco to try with if(relayed_msg==FAKED_REPLY || relayed_msg->REPLY_STATUS==uas_rb->activ_type)
Not sure if there are any other cases where relayed_msg is a NULL but we will test this and let you know if it helps.
Indeed, I noticed that is the FAKED_REPLY looking at the locals in the backtrace he sent to me. I think it is better to use relayed_code instead of relayed_msg->REPLY_STATUS in that condition.
Cheers, Daniel
Hello,
the patch should be fine for now. My review is mainly targeting to see if other tm callbacks suffer from same situation and if I can find a better solution. But for your specific case, should be ok to use as it is now.
Cheers, Daniel
On 20.11.17 12:13, Marco Capetta wrote:
Hi Daniel,
did you have time to review the fix, or can I use the last suggested patch?
Thanks!
Cheers, Marco
On 11/14/2017 08:39 AM, Daniel-Constantin Mierla wrote:
Hello,
ok, thanks for testing, good to know the issue was identified! I will do another review soon to see if there would be a better fix for the case.
Cheers, Daniel
On 13.11.17 09:46, Marco Capetta wrote:
Hi Daniel,
we left the test system running the whole weekend and so far we haven't see any new ACC record for provisional response messages. I think that the latest patch solved the issue.
Thank you
Cheers Marco
----- Original Message ----- From: "Daniel-Constantin Mierla" miconda@gmail.com To: "Kamailio (SER) - Users Mailing List" sr-users@lists.kamailio.org, "Andrew Pogrebennyk" apogrebennyk@sipwise.com Sent: Friday, November 10, 2017 9:48:29 AM Subject: Re: [SR-Users] 183 acc records even if early_media equals to 0
On 10.11.17 09:42, Andrew Pogrebennyk wrote:
On 11/10/2017 09:34 AM, Marco Capetta wrote:
+ if(relayed_msg->REPLY_STATUS==uas_rb->activ_type) { + run_trans_callbacks_with_buf( TMCB_RESPONSE_OUT, uas_rb, t->uas.request, + relayed_msg, relayed_code); + }
my guess is that in case of fake reply like a 408 the relayed_msg is -1 so addressing the member by pointer fails.
I have suggested Marco to try with if(relayed_msg==FAKED_REPLY || relayed_msg->REPLY_STATUS==uas_rb->activ_type)
Not sure if there are any other cases where relayed_msg is a NULL but we will test this and let you know if it helps.
Indeed, I noticed that is the FAKED_REPLY looking at the locals in the backtrace he sent to me. I think it is better to use relayed_code instead of relayed_msg->REPLY_STATUS in that condition.
Cheers, Daniel
-- *Marco Capetta * Operations Engineer
Sipwise GmbH http://www.sipwise.com , Campus 21/Europaring F15 AT-2345 Brunn am Gebirge
Phone: +43(0)1 301 2044 tel:+4313012044 Email: mcapetta@sipwise.com mailto:mcapetta@sipwise.com Website: www.sipwise.com http://www.sipwise.com
Particulars according Austrian Companies Code paragraph 14 "Sipwise GmbH" - Europaring F15 - 2345 Brunn am Gebirge FN:305595f, Commercial Court Vienna, ATU64002206
-
Andrew Pogrebennyk -
Daniel-Constantin Mierla -
Marco Capetta