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:
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(a)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(a)lists.sip-router.org
>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
> --
> Daniel-Constantin Mierla
>
http://www.asipto.com