Re: [sr-dev] segfault with t_suspend() / t_continue()

I did not stress test it, I only had one registered device (which sent the INVITE) , and another one was supposed to register after some event triggered by kamailio via a http query (using the utils module) - that's the reason I parked the transaction with "t_suspend()" . When the REGISTER for the second device comes I send the INVITE to the it .( lookup() , t_relay() ) . This is a scenario that works for me. I could say I tested 10 times and 1 time crashed. I plan to stress test these days, let me know if I should get some information for you while doing it.  Regards, Dragos ________________________________ From: Daniel-Constantin Mierla <miconda(a)gmail.com> To: Dragos Oancea <droancea(a)yahoo.com>om>; Kamailio (SER) - Development Mailing List <sr-dev(a)lists.sip-router.org> Sent: Thursday, April 4, 2013 8:53 PM Subject: Re: [sr-dev] segfault with t_suspend() / t_continue() Hello, at first sight looks like a missing safety check, but I may be wrong

Did you stress test it or was just casual trying? You said it

Cheers, Daniel On 4/4/13 8:28 PM, Dragos Oancea wrote: Hi Daniel, > > >Here is the output of `bt full`: >http://pastebin.com/tnrWML3L > >Let me know if I can be of any assistance further. > > >Regards, >Dragos > > > >________________________________ > From: Daniel-Constantin Mierla <miconda(a)gmail.com> >To: Dragos Oancea <droancea(a)yahoo.com>om>; Kamailio (SER) - Development Mailing List <sr-dev(a)lists.sip-router.org> >Sent: Thursday, April 4, 2013 7:28 PM >Subject: Re: [sr-dev] segfault with t_suspend() / t_continue() > > >Hello, > >could be related, but the issue seems to be while

> >Cheers, >Daniel > > >On 4/4/13 6:56 PM, Dragos Oancea wrote: > >Hello, >> >> >> >> >> >>I got the following coredump while doing some testing with t_suspend() and t_continue() on the first INVITE: >> >> >>(gdb) bt >>#0  qm_detach_free (qm=0x7fe2dae65000, size=16) at mem/q_malloc.c:269 >>#1  qm_malloc (qm=0x7fe2dae65000, size=16) at mem/q_malloc.c:386 >>#2  0x00007fe2e5e6d541 in update_totag_set (t=0x7fe2db0f42d0, ok=<value optimized out>) at t_reply.c:372 >>#3  0x00007fe2e5e72387 in relay_reply (t=<value optimized out>, p_msg=<value optimized out>, branch=2, msg_status=200, cancel_data=0x7fff63fdf9b0, do_put_on_wait=1) at t_reply.c:1854 >>#4  0x00007fe2e5e733e6 in reply_received (p_msg=0x7fe2e6a55ba0) at t_reply.c:2370 >>#5  0x00000000004547f5 in do_forward_reply (msg=0x7fe2e6a55ba0, mode=<value optimized out>) at forward.c:799 >>#6  0x000000000049a5ba in receive_msg (buf=<value optimized out>, len=961, rcv_info=0x7fff63fdfc40) at receive.c:270 >>#7  0x00000000005281a6 in udp_rcv_loop () at udp_server.c:544 >>#8  0x0000000000464d3a in main_loop () at main.c:1638 >>#9  0x0000000000467a6c in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:2566 >> >> >> >> >> >> >>I suspend the transaction in one route and then I continue it in another route, similar to below: >> >> >>route[INVITE] >># Suspend and put to memcache: >>t_suspend(); >>        xlog("proceesing suspended in transaction [$T(id_index):$T(id_label)]\n"); >>        $var(transaction_index)=$T(id_index); >>        $var(transaction_label)=$T(id_label); >>         >>        $mct(wait_$tU)= "" + $var(transaction_index) + ":" + $var(transaction_label); >>        $mctex(wait_$tU) = 100; >>} >> >> >>route[INVITE_resume]  { >> >> >># get the transaction index and lable from memcache  >>    $avp(check) = $mct(wait_$tU) ; # I should have the transaction index and the transaction label here  >>    $var(my_transaction_index) =  $(avp(check){s.select,0,:}); >>    $var(my_transaction_label) =  $(avp(check){s.select,1,:}); >>    $var(a)= $(var(my_transaction_index){s.int}); >>    $var(b) = $(var(my_transaction_label){s.int}); >> >> >>    t_continue( "$var(a)",  "$var(b)" , "my_relay_route"); >>} >>  >> >> >>route[INVITE_resume] executes only on an asynchronous event (a certain SIP message that might come or not) .  >> >> >>I use kamailio 4.0.0/Centos Linux. I suspect it happened when I sent CANCEL, but I could not reproduce. I still have the core file. >> >> >>Regards, >>Dragos >> >> >> >> >>_______________________________________________

> >--

--

_______________________________________________ sr-dev mailing list sr-dev(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev