Please keep the mailing list cc-ed. Private emails from the lists are the last checked and usually dropped after first notice.
Are you running the 3.1.0 from tarball? There was a fix related to cancel processing with new addition of reason header support. Although it does not look to be right there, might be related, since it is processing of a cancelled transaction.
Could you try with latest version of GIT branch 3.1? If you use debs, then you can take the nightly builds. Anyhow, for any eventuality, here is a guide: http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-3.1.x-from-git
Cheers, Daniel
On 10/26/10 6:08 PM, Mino Haluz wrote:
Hm maybe it is something with radiusclient ...
(gdb) bt #0 0xb70dbf73 in rc_avpair_assign () from /usr/lib/libradiusclient-ng.so.2 #1 0xb70dc059 in rc_avpair_new () from /usr/lib/libradiusclient-ng.so.2 #2 0xb70dc1ae in rc_avpair_add () from /usr/lib/libradiusclient-ng.so.2 #3 0xb70ec745 in acc_rad_request (req=0xb7292fc0) at acc.c:585 #4 0xb70ef9d0 in on_missed (t=<value optimized out>, req=0xb7292fc0, reply=0x8353da8, code=487) at acc_logic.c:328 #5 0xb7239067 in run_trans_callbacks_internal (cb_lst=0xb5161b70, type=64, trans=0xb5161b30, params=0xbf896cbc) at t_hooks.c:290 #6 0xb72392fa in run_trans_callbacks (type=64, trans=0xb5161b30, req=0xb7292fc0, rpl=0x8353da8, code=487) at t_hooks.c:317 #7 0xb725df6e in run_failure_handlers (t=0xb5161b30, rpl=0x8353da8, code=487, extra_flags=64) at t_reply.c:948 #8 0xb725f28c in t_should_relay_response (Trans=0xb5161b30, new_code=<value optimized out>, branch=0, should_store=0xbf896ec8, should_relay=0xbf896ecc, cancel_data=0xbf8970a0, reply=0x8353da8) at t_reply.c:1212 #9 0xb7262bf1 in relay_reply (t=0xb5161b30, p_msg=0x8353da8, branch=0, msg_status=487, cancel_data=0xbf8970a0, do_put_on_wait=1) at t_reply.c:1615 #10 0xb7265c15 in reply_received (p_msg=0x8353da8) at t_reply.c:2284 #11 0x080929cc in forward_reply (msg=0x8353da8) at forward.c:768 #12 0x080d57d5 in receive_msg ( buf=0x827e740 "SIP/2.0 487 Request Cancelled\r\nVia: SIP/2.0/UDP 1.1.1.1;branch=z9hG4bK01a2.35a963e6.0,SIP/2.0/UDP 192.168.10.4:5070;received=2.2.2.2;rport=1081;branch=z9hG4bK1902564\r\nFrom: "zxc"<sip:004"..., len=492, rcv_info=<value optimized out>) at receive.c:266 #13 0x0815b532 in udp_rcv_loop () at udp_server.c:532 #14 0x080a2917 in main_loop () at main.c:1554 #15 0x080a5142 in main (argc=1, argv=0xbf8975b4) at main.c:2398
On Tue, Oct 26, 2010 at 5:43 PM, Daniel-Constantin Mierla miconda@gmail.com wrote:
Hello,
On 10/26/10 3:18 PM, Mino Haluz wrote:
Hi,
there seems to be a bug when using multi_leg_info (version: kamailio 3.1.0 (i386/linux) bf8b8d):
modparam("acc", "multi_leg_info", "Src-Leg=$avp(i:901);Dst-Leg=$avp(i:902)")
When the call ends, kamailio suddenly segfaults:
WARNING: no fork mode Segmentation fault (core dumped)
you got a core file, locate it in / or in the working directory.
The do:
gdb /path/to/kamailio /path/to/core
bt
Send the output here.
Cheers, Daniel
If you do not know to reproduce the error, please provide a howto that can lead me to retrieve another useful information (gdb..). Thank you very much.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla http://www.asipto.com
-
Daniel-Constantin Mierla