Hello,
what version do you have? If it is for 3.0, please register a bug at:
http://sip-router.org/tracker/
In 3.0 the crash is at:
186 case HDR_REFER_TO_T:
187 free_to(hf->parsed);
188 break;
I am out of the office without my linux box these days to be able to check
more. Maybe some other devel can look a bit at it.
Thanks,
Daniel
On Wed, Mar 10, 2010 at 9:17 AM, Panagiotis Skoulikaritis <pskoul(a)algonet.gr
> wrote:
> Dear fellow kaimailio users
>
> We have a kamailio server which crashes.
> below is the backtrace from the core files
> any idea why the kamailio is crashing
>
> Regards
>
> Panagiotis
>
> core.29568 Mar 10 09:27
>
> #0 fm_status (qm=0x73a040) at mem/f_malloc.c:609
> #1 0x0000000000423d5c in sig_usr (signo=15) at main.c:563
> #2 <signal handler called>
> #3 0x00000037e3cd4711 in __recvfrom_nocancel () from /lib64/libc.so.6
> #4 0x00000000004790cc in udp_rcv_loop () at udp_server.c:408
> #5 0x000000000042760e in main (argc=3, argv=0x7fff8bf6abc8) at main.c:774
>
>
>
>
>
> core.19350 Mar 10 09:05
>
> (gdb) backtrace
> #0 free_to (tb=0x775c00) at parser/parse_to.c:79
> #1 0x000000000047fd42 in clean_hdr_field (hf=0x2ad2432de100) at
> parser/hf.c:187
> #2 0x00002ad23fe3e525 in run_trans_callbacks (type=<value optimized out>,
> trans=<value optimized out>, req=0x2ad2432dcf58,
> rpl=0x772d28, code=<value optimized out>) at sip_msg.h:54
> #3 0x00002ad23fe47b46 in t_reply_matching (p_msg=0x772d28, p_branch=<value
> optimized out>) at t_lookup.c:888
> #4 0x00002ad23fe47fa2 in t_check (p_msg=0x772d28,
> param_branch=0x7ffff9c016bc) at t_lookup.c:964
> #5 0x00002ad23fe58ac2 in reply_received (p_msg=0x73a040) at t_reply.c:1395
> #6 0x000000000041eebc in forward_reply (msg=0x772d28) at forward.c:521
> #7 0x0000000000445313 in receive_msg (
> buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 77.247.97.11;branch=z9hG4bK45f7.70f91294.0;received=77.247.97.11\r\nV",
> len=920, rcv_info=0x7ffff9c017a0) at receive.c:212
> #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449
> #9 0x000000000042760e in main (argc=3, argv=0x7ffff9c019b8) at main.c:774
> (gdb)
>
>
>
>
> core.29567 Mar 10 09:27
>
> gdb) backtrace
> #0 free_to (tb=0x776460) at parser/parse_to.c:79
> #1 0x000000000047fd42 in clean_hdr_field (hf=0x2ad1805fa100) at
> parser/hf.c:187
> #2 0x00002ad17d15a525 in run_trans_callbacks (type=<value optimized out>,
> trans=<value optimized out>, req=0x2ad1805f8f58,
> rpl=0x771920, code=<value optimized out>) at sip_msg.h:54
> #3 0x00002ad17d163b46 in t_reply_matching (p_msg=0x771920, p_branch=<value
> optimized out>) at t_lookup.c:888
> #4 0x00002ad17d163fa2 in t_check (p_msg=0x771920,
> param_branch=0x7fff8bf6a8cc) at t_lookup.c:964
> #5 0x00002ad17d174ac2 in reply_received (p_msg=0x73a040) at t_reply.c:1395
> #6 0x000000000041eebc in forward_reply (msg=0x771920) at forward.c:521
> #7 0x0000000000445313 in receive_msg (
> buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 77.247.97.11;branch=z9hG4bKddc9.fa58f7e.0;received=77.247.97.11\r\nVia:
> SIP/2.0/UDP 213.170.194.47:5060;branch=z9hG4bKb973f6a69c9bea270e9db867dd7cc90f\r\nRecord-Route:
> <si"..., len=919, rcv_info=0x7fff8bf6a9b0)
> at receive.c:212
> #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449
> #9 0x000000000042760e in main (argc=3, argv=0x7fff8bf6abc8) at main.c:774
> (gdb)
>
>
> core.5326 Mar 10 09:02
>
> (gdb) backtrace
> #0 free_to (tb=0x772c48) at parser/parse_to.c:79
> #1 0x000000000047fd42 in clean_hdr_field (hf=0x2b2578e22560) at
> parser/hf.c:187
> #2 0x00002b257597b525 in run_trans_callbacks (type=<value optimized out>,
> trans=<value optimized out>, req=0x2b2578e213b8,
> rpl=0x771b50, code=<value optimized out>) at sip_msg.h:54
> #3 0x00002b2575984b46 in t_reply_matching (p_msg=0x771b50, p_branch=<value
> optimized out>) at t_lookup.c:888
> #4 0x00002b2575984fa2 in t_check (p_msg=0x771b50,
> param_branch=0x7fff7cdc63ac) at t_lookup.c:964
> #5 0x00002b2575995ac2 in reply_received (p_msg=0x772c48) at t_reply.c:1395
> #6 0x000000000041eebc in forward_reply (msg=0x771b50) at forward.c:521
> #7 0x0000000000445313 in receive_msg (
> buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP
> 77.247.97.11;branch=z9hG4bKec2f.dc3d97a7.0;received=77.247.97.11\r\nVia:
> SIP/2.0/UDP 213.170.194.47:5060;branch=z9hG4bK47703457194f5be415efc231f6b3e923\r\nRecord-Route:
> <s"..., len=918, rcv_info=0x7fff7cdc6490)
> at receive.c:212
> #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449
> #9 0x000000000042760e in main (argc=5, argv=0x7fff7cdc66a8) at main.c:774
> (gdb) quit
>
> _______________________________________________
> Kamailio (OpenSER) - Users mailing list
> Users(a)lists.kamailio.org
> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
>
--
Daniel-Constantin Mierla
http://www.asipto.com
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss
User who did this - Ronald Voermans (voermans)
----------
Other thing: with the current database setup: the username isn't part of the primary key any more. So an insert always works, and there is never going to be an update. Just tried it, and the table is full of duplicates! If that patch makes it into Kamailio, the database structure for the location-table needs to be adjusted!
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=41#comment37
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss
User who did this - Ronald Voermans (voermans)
----------
When restarting Kamailio, I thought it retreived the registrations from the location-table. Correct? If so, all should be consistent. But for some reason, it is/was not. Is the memory location preserved when restarting Kamailio?
To be honest: i don't really know what the expected behaviour should be. When using db_mode("1"), what exactly is the use of the location-table?
I do expect the memory location to be available when the database is not. On the other hand: when an update isn't possible, I do think it the location-entry should be inserted (or, as you state it the other way around: first INSERT, if that fails, UPDATE).
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=41#comment36
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.