You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Resetting an htable from kemi causes a segfault.
KSR.htable.sht_reset(self._htable)#0 0x00007f466dad1c06 in core_case_hash (s1=0x7f4672556ec8, s2=0x0, size=0) at ../../core/hashes.h:317
#1 0x00007f466dad3731 in ht_get_table (name=0x7f4672556ec8) at ht_api.c:240
#2 0x00007f466daeabf4 in ht_reset_by_name (hname=0x7f4672556ec8) at htable.c:669
#3 0x00007f466ed83515 in sr_apy_kemi_exec_func_ex (ket=0x7f466dd0f730 <sr_kemi_htable_exports+144>, self=0x0, args=0x7f4673504b10, idx=303) at apy_kemi.c:438
#4 0x00007f466ed87633 in sr_apy_kemi_exec_func (self=0x0, args=0x7f4673504b10, idx=303) at apy_kemi.c:692
#5 0x00007f466ed706ad in sr_apy_kemi_exec_func_303 (self=0x0, args=0x7f4673504b10) at apy_kemi_export.c:2467
#6 0x00007f466e854091 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#7 0x00007f466e852390 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#8 0x00007f466e852390 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#9 0x00007f466e852390 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#10 0x00007f466e852390 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#11 0x00007f466e9bb29c in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#12 0x00007f466e90f76d in ?? () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#13 0x00007f466e8a75c3 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#14 0x00007f466e84f247 in PyEval_EvalFrameEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#15 0x00007f466e9bb29c in PyEval_EvalCodeEx () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#16 0x00007f466e90f670 in ?? () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#17 0x00007f466e8a75c3 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#18 0x00007f466e964dfc in ?? () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#19 0x00007f466e8a75c3 in PyObject_Call () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#20 0x00007f466e9ba6c7 in PyEval_CallObjectWithKeywords () from /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0
#21 0x00007f466eda041f in apy_exec (_msg=0x7f4672556ec8, fname=0x560e4d8eadf8 "ksr_reply_route", fparam=0x0, emode=0) at python_exec.c:145
#22 0x00007f466ed781ae in sr_kemi_config_engine_python (msg=0x7f4672556ec8, rtype=128, rname=0x0, rparam=0x0) at apy_kemi.c:67
#23 0x0000560e4d5fb64c in sr_kemi_route (keng=0x560e4dbdcf60 <_sr_kemi_eng_list>, msg=0x7f4672556ec8, rtype=128, ename=0x0, edata=0x0) at core/kemi.c:2421
#24 0x0000560e4d6d7c57 in receive_msg (buf=0x560e4ed34d30 "SIP/2.0 200 OK\r\nRecord-Route: <sip:sipcore;transport=tcp;lr;nat=yes>\r\nVia: SIP/2.0/TCP 172.16.214.19:5060;rport=41056;received=172.28.1.4;branch=z9hG4bK4c66.ff59d957", '0' <repeats 24 times>, ".0\r\nTo: <si"...,
len=515, rcv_info=0x7f46694cc418) at core/receive.c:408
#25 0x0000560e4d776eb5 in receive_tcp_msg (
tcpbuf=0x7f46694cc6f8 "SIP/2.0 200 OK\r\nRecord-Route: <sip:sipcore;transport=tcp;lr;nat=yes>\r\nVia: SIP/2.0/TCP 172.16.214.19:5060;rport=41056;received=172.28.1.4;branch=z9hG4bK4c66.ff59d957", '0' <repeats 24 times>, ".0\r\nTo: <si"..., len=515,
rcv_info=0x7f46694cc418, con=0x7f46694cc400) at core/tcp_read.c:1448
#26 0x0000560e4d779192 in tcp_read_req (con=0x7f46694cc400, bytes_read=0x7fff72893524, read_flags=0x7fff7289352c) at core/tcp_read.c:1631
#27 0x0000560e4d77cdb9 in handle_io (fm=0x7f4672544500, events=1, idx=-1) at core/tcp_read.c:1862
#28 0x0000560e4d7696ad in io_wait_loop_epoll (h=0x560e4dc371a0 <io_w>, t=2, repeat=0) at core/io_wait.h:1065
#29 0x0000560e4d77e18f in tcp_receive_loop (unix_sock=22) at core/tcp_read.c:1974
#30 0x0000560e4d6503b3 in tcp_init_children () at core/tcp_main.c:4853
#31 0x0000560e4d54a86d in main_loop () at main.c:1745
#32 0x0000560e4d55199d in main (argc=5, argv=0x7fff72893bc8) at main.c:2696
(gdb) frame
#2 0x00007f466daeabf4 in ht_reset_by_name (hname=0x7f4672556ec8) at htable.c:669
669 ht = ht_get_table(hname);
(gdb) list
664 }
665
666 static int ht_reset_by_name(str *hname)
667 {
668 ht_t *ht;
669 ht = ht_get_table(hname);
670 if(ht==NULL) {
671 LM_ERR("cannot get hash table [%.*s]\n", hname->len, hname->s);
672 return -1;
673 }
(gdb) p hname
hname hname_data hname_fixup
(gdb) p hname.
len s
(gdb) p hname.len
$10 = 1556597679
(gdb) p hname.s
$11 = 0x720000000c <error: Cannot access memory at address 0x720000000c>
May 1 10:18:56 ws3171 lmrncf[1893]: 0(1) INFO: <core> [main.c:772]: handle_sigs(): SIGCHLD received, but no child has stopped, ignoring it
May 1 10:18:56 ws3171 lmrncf[1893]: 6(110) INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config)
May 1 10:18:59 ws3171 lmrncf[1893]: 7(111) INFO: [Media] Media connected to ('172.28.1.8', 53350)
May 1 10:19:03 ws3171 lmrncf[1893]: 10(114) INFO: {1 1 REGISTER MLqF3GJQD6ZcDgNvd4clLg..} [LMR] Registered gateway IP: 172.16.195.127
May 1 10:19:03 ws3171 lmrncf[1893]: 10(114) INFO: {1 1 REGISTER MLqF3GJQD6ZcDgNvd4clLg..} <core> [core/tcp_main.c:2703]: tcpconn_1st_send(): quick connect for 0x7f2bf92a59e0
May 1 10:19:03 ws3171 lmrncf[1893]: 11(115) ERROR: {2 10 SUBSCRIBE 358eceb71627d8e0-114@172.28.1.4} [PoC] Subscribe failed with code 404
May 1 10:19:03 ws3171 lmrncf[1893]: 11(115) ERROR: {2 10 SUBSCRIBE 358eceb71627d8e0-114@172.28.1.4} crumb 1
May 1 10:19:03 ws3171 lmrncf[1893]: 11(115) ERROR: {2 10 SUBSCRIBE 358eceb71627d8e0-114@172.28.1.4} crumb -- hmmm here goes reset -- affiliation_groups
May 1 10:19:03 ws3171 lmrncf[1893]: 12(116) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 20
May 1 10:19:03 ws3171 lmrncf[1893]: 0(1) ALERT: <core> [main.c:755]: handle_sigs(): child process 115 exited by a signal 11
May 1 10:19:03 ws3171 lmrncf[1893]: 0(1) ALERT: <core> [main.c:758]: handle_sigs(): core was generated
May 1 10:19:03 ws3171 lmrncf[1893]: 0(1) INFO: <core> [main.c:781]: handle_sigs(): terminating due to SIGCHLD
It appears that because the kemi htable jump-table references ht_reset_by_name (without ki_ prefix) for sht_reset it will be called with msg as first argument but ht_reset_by_name doesn't accept msg context at all -- its only argument is the name of the htable of interest.
static sr_kemi_t sr_kemi_htable_exports[] = {
{ str_init("htable"), str_init("sht_lock"),
SR_KEMIP_INT, ki_ht_slot_lock,
{ SR_KEMIP_STR, SR_KEMIP_STR, SR_KEMIP_NONE,
SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE }
},
{ str_init("htable"), str_init("sht_unlock"),
SR_KEMIP_INT, ki_ht_slot_unlock,
{ SR_KEMIP_STR, SR_KEMIP_STR, SR_KEMIP_NONE,
SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE }
},
{ str_init("htable"), str_init("sht_reset"),
SR_KEMIP_INT, ht_reset_by_name,
{ SR_KEMIP_STR, SR_KEMIP_NONE, SR_KEMIP_NONE,
SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE }
},
{ str_init("htable"), str_init("sht_iterator_start"),
SR_KEMIP_INT, ki_ht_iterator_start,
{ SR_KEMIP_STR, SR_KEMIP_STR, SR_KEMIP_NONE,
SR_KEMIP_NONE, SR_KEMIP_NONE, SR_KEMIP_NONE }
},
{ str_init("htable"), str_init("sht_iterator_next"),
SR_KEMIP_INT, ki_ht_iterator_next,static int ht_reset_by_name(str *hname);kamailio -vkamcmd 1.5
Copyright 2006 iptelorg GmbH
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
kamcmd> ver
kamailio 5.2.2 (x86_64/linux)
kamcmd>
Linux b8af694f9887 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 GNU/Linux
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.