[sr-dev] segfault

[Kelvin Chua]

argh, ignore last 2 emails, it's all a mess

Kelvin Chua

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

> 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/20160919/04eb4b0c/attachment.html>