[sr-dev] segfault

Kelvin Chua kelchy at gmail.com
Sun Sep 18 17:33:08 CEST 2016


please disregard the last email, i got tons of core dumps. chose the wrong
one.

this however is the correct one, something to do with dmq and/or dlg

#0  0x00000000006415dc in fm_extract_free (qm=0x7f32df357000,
frag=0x7f32df6af038) at mem/f_malloc.c:185
#1  0x0000000000642ded in fm_malloc (qmp=0x7f32df357000, size=40,
file=0x7f32dd3a6d12 "tm: dlg.c", func=0x7f32dd3a9a4c <__FUNCTION__.9570>
"str_duplicate", line=195,
    mname=0x7f32dd3a67c0 "tm") at mem/f_malloc.c:497
#2  0x0000000000648d6a in fm_shm_malloc (qmp=0x7f32df357000, size=37,
file=0x7f32dd3a6d12 "tm: dlg.c", func=0x7f32dd3a9a4c <__FUNCTION__.9570>
"str_duplicate", line=195,
    mname=0x7f32dd3a67c0 "tm") at mem/f_malloc.c:1088
#3  0x00007f32dd2d024f in str_duplicate (_d=0x7f32df6afa78,
_s=0x7fff74b7ff80) at dlg.c:195
#4  0x00007f32dd2d13f4 in new_dlg_uac (_cid=0x7fff74b7ff70,
_ltag=0x7fff74b7ff80, _lseq=10, _luri=0x7fff74b80070, _ruri=0x7fff74b80080,
_d=0x7fff74b7ff68) at dlg.c:325
#5  0x00007f32dd3a4e46 in request (uac_r=0x7fff74b80090,
ruri=0x7fff74b80080, to=0x7fff74b80080, from=0x7fff74b80070, next_hop=0x0)
at uac.c:882
#6  0x00007f32db84c07f in dmq_send_message (peer=0x7f32df605b20,
body=0x7fff74b802c0, node=0x7f32df67dd90, resp_cback=0x7f32d9e9ed90
<ht_dmq_resp_callback>, max_forwards=1,
    content_type=0x7f32d9e9ed50 <ht_dmq_content_type>) at dmq_funcs.c:239
#7  0x00007f32db84a6fd in bcast_dmq_message (peer=0x7f32df605b20,
body=0x7fff74b802c0, except=0x0, resp_cback=0x7f32d9e9ed90
<ht_dmq_resp_callback>, max_forwards=1,
    content_type=0x7f32d9e9ed50 <ht_dmq_content_type>) at dmq_funcs.c:167
#8  0x00007f32d9c89ed6 in ht_dmq_broadcast (body=0x7fff74b802c0) at
ht_dmq.c:86
#9  0x00007f32d9c8ca25 in ht_dmq_replicate_action (action=HT_DMQ_SET_CELL,
htname=0x7f32e6b7cdd0, cname=0x7fff74b803c0, type=0, val=0x7fff74b803d0,
mode=1) at ht_dmq.c:224
#10 0x00007f32d9c8eb49 in pv_set_ht_cell (msg=0x7f32e6c8cfd0,
param=0x7f32e6b7cd18, op=254, val=0x7fff74b804a0) at ht_var.c:104
#11 0x00000000004a68a1 in lval_pvar_assign (h=0x7fff74b82f40,
msg=0x7f32e6c8cfd0, lv=0x7f32e6c00c28, rv=0x7f32e6c43a80) at lvalue.c:351
#12 0x00000000004a72bf in lval_assign (h=0x7fff74b82f40,
msg=0x7f32e6c8cfd0, lv=0x7f32e6c00c28, rve=0x7f32e6c04f20) at lvalue.c:399
#13 0x000000000042aad1 in do_action (h=0x7fff74b82f40, a=0x7f32e6c05630,
msg=0x7f32e6c8cfd0) at action.c:1430
#14 0x000000000042c5aa in run_actions (h=0x7fff74b82f40, a=0x7f32e6c05630,
msg=0x7f32e6c8cfd0) at action.c:1549
#15 0x000000000041f68e in do_action (h=0x7fff74b82f40, a=0x7f32e6c05760,
msg=0x7f32e6c8cfd0) at action.c:1045
#16 0x000000000042c5aa in run_actions (h=0x7fff74b82f40, a=0x7f32e6c05760,
msg=0x7f32e6c8cfd0) at action.c:1549
#17 0x0000000000428ccd in do_action (h=0x7fff74b82f40, a=0x7f32e6c096e8,
msg=0x7f32e6c8cfd0) at action.c:1190
#18 0x000000000042c5aa in run_actions (h=0x7fff74b82f40, a=0x7f32e6c096e8,
msg=0x7f32e6c8cfd0) at action.c:1549
#19 0x000000000041f68e in do_action (h=0x7fff74b82f40, a=0x7f32e6c0a5f8,
msg=0x7f32e6c8cfd0) at action.c:1045
#20 0x000000000042c5aa in run_actions (h=0x7fff74b82f40, a=0x7f32e6bffc88,
msg=0x7f32e6c8cfd0) at action.c:1549
#21 0x000000000041f68e in do_action (h=0x7fff74b82f40, a=0x7f32e6c1bd48,
msg=0x7f32e6c8cfd0) at action.c:1045
#22 0x000000000042c5aa in run_actions (h=0x7fff74b82f40, a=0x7f32e6bf4860,
msg=0x7f32e6c8cfd0) at action.c:1549
#23 0x000000000041bee8 in do_action (h=0x7fff74b82f40, a=0x7f32e6947f38,
msg=0x7f32e6c8cfd0) at action.c:678
#24 0x000000000042c5aa in run_actions (h=0x7fff74b82f40, a=0x7f32e69244e0,
msg=0x7f32e6c8cfd0) at action.c:1549
#25 0x000000000042cd53 in run_top_route (a=0x7f32e69244e0,
msg=0x7f32e6c8cfd0, c=0x0) at action.c:1635
#26 0x000000000051d57a in receive_msg (
    buf=0xabb500 <buf> "REGISTER sip:circles.asia SIP/2.0\r\nVia:
SIP/2.0/UDP 52.76.180.17:6055;branch=z9hG4bKffef.59d1d352de0cecdff4c154832f661f64.0;i=333\r\nVia:
SIP/2.0/TLS 192.168.0.160:42733;received=27.125.145.22;branch=z9"...,
len=1198, rcv_info=0x7fff74b832b0) at receive.c:240
#27 0x00000000006302f1 in udp_rcv_loop () at udp_server.c:495
#28 0x00000000004b3062 in main_loop () at main.c:1600
#29 0x00000000004ba772 in main (argc=13, argv=0x7fff74b837b8) at main.c:2616


Kelvin Chua

On Sun, Sep 18, 2016 at 5:00 PM, Kelvin Chua <kelchy at gmail.com> wrote:

> any tips on how to easily fix this?
>
> (gdb) bt
> #0  0x0000000000558300 in rve_destroy (rve=0x632e656c706d6178) at
> rvalue.c:147
> #1  0x0000000000558b70 in rve_destroy (rve=0x7f811148dcc8) at rvalue.c:168
> #2  0x0000000000725272 in free_mod_func_action (a=0x7f811148da58) at
> cfg.y:3820
> #3  0x0000000000721281 in yyparse () at cfg.y:3236
> #4  0x00000000004b67e6 in main (argc=6, argv=0x7ffd3f866798) at main.c:2117
>
>
>
> Kelvin Chua
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20160918/24c4510c/attachment.html>


More information about the sr-dev mailing list