sr-dev February 2021

sr-dev@lists.kamailio.org

20 participants
251 discussions

[kamailio/kamailio] xavp set in event_route[tm:local-request] are not used in SIP transaction (#2413)
by arkadiam 31 Mar '21

31 Mar '21

### Description I'm using dispatcher module like: ``` loadmodule "dispatcher.so" modparam("dispatcher", "list_file", "/etc/kamailio/dispatcher.list") modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_ping_interval", 60) ``` With records like: ``` 1 sip:sip.host.com;transport=tls 0 1 socket=tls:111.222.233.10:5061;ping_from=sip:my-domain-01.com 2 sip:sip.host.com;transport=tls 0 1 socket=tls:111.222.233.20:5061;ping_from=sip:my-domain-02.com ``` In event_route[tm:local-request] I'm modifying 'Contact' and would like to specify what client TLS profile to use via server name or server id. ``` event_route[tm:local-request] { if(is_method("OPTIONS")) { append_hf("Contact: <sip:some-host.com;transport=tls>\r\n"); $xavp(tls=>server_name)=$fd; $xavp(tls[0]=>server_id)=$fd; } } ``` Setting 'tls' xavp doesn't make any difference and default client TLS profile is being used. It happens because in src/modules/tm/uac.c there is a code: ``` t_run_local_req() ... tm_xdata_swap(new_cell, &backup_xd, 0); ... /* restore original environment */ tm_xdata_swap(new_cell, &backup_xd, 1); ``` which resets any xavp changes done in event_route[tm:local-request]. Expected behaviour: ability to use xavp in tm:local-request route. That would allow to choose TLS client profile for dispatcher initiated requests. ### Possible Solutions As a hack, in tm_xdata_swap() for mode=1, don't restore xavp list if it was NULL. ``` if (x->xavps_list != NULL && *x->xavps_list==NULL) { // .... don't restore empty list... } else { xavp_set_list(x->xavps_list); } ``` This change allows to select required TLS profile for dispatcher requests. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.5 (x86_64/linux) ff2f8c-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: ff2f8c -dirty compiled on 10:19:05 Jul 28 2020 with gcc 7.5.0 ``` * **Operating System**: ``` Linux xx 4.15.0-111-generic #112-Ubuntu SMP Thu Jul 9 20:32:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2413

2 4

[kamailio/kamailio] topos+topos_redis TTL for SUBSCRIBE (#2652)
by goharahmed 31 Mar '21

31 Mar '21

### Description topos_redis sets TTL on dialogs including presence SUBSCRIPTIONs. Once the TTL expires on those SUBSCRIBEs the topos module fails to route the in-dialog NOTIFYs & subsequent SUBSCRIBEs. That causes presence to break.  ### Troubleshooting ``` loadmodule "topos_redis.so" modparam("topos_redis", "serverid", "srv1") loadmodule "topos.so" modparam("topos", "storage", "redis") ``` #### Reproduction load up topos and topos_redis module, set expiration in topos_redis to 600 (just to reproduce this) create a dialog, either INVITE or SUBSCRIBE anything is fine. Once the TTL is expired the in-dialog routing of packets fail in route[WITHINDLG] with 404 Not here. The route[WITHINGDLG] is just the standard one for us(can be pasted when needed) I can set the TTL to few days, but doing that brought the problem back for SUBSCRIBEs since the desk phone stay alive for weeks at a stretch.  ### Possible Solutions I could only think about renewing/refreshing the TTL for dialogs whenever they're loaded, so I modified the topos and topos_redis module for this and tested it. so far it works well and SUBSCRIBEs/NOTIFYs have been getting routed perfectly fine over the course of a week+  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.4.3 (x86_64/linux) a96451-dirty flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: a96451 -dirty compiled on 23:44:16 Feb 20 2021 with gcc 8.3.0 ``` * **Operating System**:  ``` Debian GNU/Linux 10 (buster) Linux sbc-va-2 4.19.0-13-cloud-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux ``` * **Suggested Fix/Patch**: https://github.com/kamailio/kamailio/compare/master...goharahmed:master -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2652

2 7

[kamailio/kamailio] Create dialog_publish.c (#2617)
by Jake Greene 31 Mar '21

31 Mar '21

pua_dialoginfo: Add display attributes to identity tags. - This is an example of how "display" attributes could be added to identity tags in the PUBLISH message XML body. - This is not a working solution, the strings("RemoteCallerName" & "LocalCallerName") are "hard coded". I could not figure out how to get the caller/callee information from the SIP message.   #### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #2615 #### Description This is not a working solution. Opening the PR as requested by @miconda in issue #2615. I just added a couple lines to test how adding a "display" attribute to the identity tags would look like. This allows the phone to update it's display with relevant caller/callee information. I "hard coded" the values to verify that this works. However, I could not figure out how to get the display name from the SIP message(I'm not experienced with C). It seems that the "local" identity should have it's display name set to the name in the From header. And, the remote identity should have its display name set to the user part of the URI in the "To" header. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/2617 -- Commit Summary -- * Create dialog_publish.c -- File Changes -- M src/modules/pua_dialoginfo/dialog_publish.c (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/2617.patch https://github.com/kamailio/kamailio/pull/2617.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/2617

2 6

[kamailio/kamailio] Kamailio 5.4.2 - CentOS 7 - qm_free(): BUG: freeing already freed pointer, called from core: core/usr_avp.c: destroy_avp_list_unsafe (#2620)
by Ryan Gehrig 29 Mar '21

29 Mar '21

Hi, Same issue with @farnk05 on https://github.com/kamailio/kamailio/issues/2224 Wanted to open a fresh issue to not reopen an old one. This is on kamailio 5.4.2, which appears to have these fixes from https://github.com/kamailio/kamailio/issues/2224#issuecomment-602730307 in them when I checked the src files. ``` $ sudo rpm -qi kamailio |grep Date Install Date: Fri 20 Nov 2020 12:03:26 AM PST Build Date : Tue 27 Oct 2020 05:37:31 AM PDT ``` ``` $ sudo rpm -qa | grep kamailio kamailio-mysql-5.4.2-0.el7.x86_64 kamailio-tls-5.4.2-0.el7.x86_64 kamailio-5.4.2-0.el7.x86_64 kamailio-websocket-5.4.2-0.el7.x86_64 kamailio-tcpops-5.4.2-0.el7.x86_64 kamailio-statsd-5.4.2-0.el7.x86_64 ``` Package Source: https://rpm.kamailio.org/centos/7/5.4/5.4.2/x86_64/ OS: RHEL 7.6.1810 Mem mgr: default/qm SHM is 4096, PKG is 1024 (system has 16gb ram, 4 core Intel Skylake CPU on a KVM. There are a few variations we see with the qm_free errors, here are the most common we see when kamailio segfaults, and we have to let systemd restart it, or Monit as we now have to have Monit check for CRITICAL messages since kamailio segfaults so often. ``` /usr/sbin/kamailio[32734]: CRITICAL: <core> [core/mem/q_malloc.c:521]: qm_free(): BUG: freeing already freed pointer (0x7f0da5012fc0), called from core: core/usr_avp.c: destroy_avp_list_unsafe(626), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring /usr/sbin/kamailio[32734]: CRITICAL: <core> [core/mem/q_malloc.c:521]: qm_free(): BUG: freeing already freed pointer (0x7f0da5012fc0), called from core: core/usr_avp.c: destroy_avp_list_unsafe(626), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring ... ``` ``` /usr/sbin/kamailio[32733]: CRITICAL: dialog [dlg_profile.c:574]: set_dlg_profile(): BUG - dialog not found in a non REQUEST route (1) /usr/sbin/kamailio[32733]: CRITICAL: dialog [dlg_profile.c:574]: set_dlg_profile(): BUG - dialog not found in a non REQUEST route (1) /usr/sbin/kamailio[6160]: CRITICAL: <core> [core/mem/q_malloc.c:521]: qm_free(): BUG: freeing already freed pointer (0x7ff00842e320), called from tm: h_table.c: free_cell_helper(189), first free core: core/usr_avp.c: destroy_avp_list_unsafe(626) - ignoring ``` GDB as requested in the other Issue (note gdb was run on another VM, not the main system, hopefully that is not an issue: ``` $ gdb /usr/sbin/kamailio /core-kamailio-11-995-992-11912-1612143069 GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-114.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/kamailio...Reading symbols from /usr/lib/debug/usr/sbin/kamailio.debug...done. done. [New LWP 11912] warning: .dynamic section for "/lib64/libc.so.6" is not at the expected address (wrong library or version mismatch?) [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by '/usr/sbin/kamailio -DD -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamai'. Program terminated with signal 11, Segmentation fault. #0 0x00000000006024be in destroy_avp_list_unsafe (list=0x7fdc559d4fd8) at core/usr_avp.c:625 625 avp = avp->next; Missing separate debuginfos, use: debuginfo-install glibc-2.17-260.el7_6.6.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-37.el7_6.x86_64 libcom_err-1.42.9-13.el7.x86_64 libgcc-4.8.5-36.el7_6.2.x86_64 libmaxminddb-1.2.0-1.el7.x86_64 libselinux-2.5-14.1.el7.x86_64 libstdc++-4.8.5-36.el7_6.2.x86_64 libunistring-0.9.3-9.el7.x86_64 mariadb-libs-5.5.60-1.el7_5.x86_64 openssl-libs-1.0.2k-16.el7_6.1.x86_64 pcre-8.32-17.el7.x86_64 zlib-1.2.7-18.el7.x86_64 (gdb) frame 0 #0 0x00000000006024be in destroy_avp_list_unsafe (list=0x7fdc559d4fd8) at core/usr_avp.c:625 625 avp = avp->next; (gdb) list 620 avp_t *avp, *foo; 621 622 avp = *list; 623 while( avp ) { 624 foo = avp; 625 avp = avp->next; 626 shm_free_unsafe( foo ); 627 } 628 *list = 0; 629 } (gdb) p *p_entry No symbol "p_entry" in current context. (gdb) p *l No symbol "l" in current context. (gdb) No symbol "l" in current context. (gdb) p *lh No symbol "lh" in current context. (gdb) p *lh No symbol "lh" in current context. (gdb) frame 1 #1 0x00007fdd56fb8f92 in free_cell_helper (dead_cell=0x7fdc559d4dd8, silent=0, fname=0x7fdd570d1363 "timer.c", fline=643) at h_table.c:255 255 destroy_avp_list_unsafe(&dead_cell->uri_avps_from); (gdb) #1 0x00007fdd56fb8f92 in free_cell_helper (dead_cell=0x7fdc559d4dd8, silent=0, fname=0x7fdd570d1363 "timer.c", fline=643) at h_table.c:255 255 destroy_avp_list_unsafe(&dead_cell->uri_avps_from); (gdb) list 250 if(dead_cell->user_avps_from) 251 destroy_avp_list_unsafe(&dead_cell->user_avps_from); 252 if(dead_cell->user_avps_to) 253 destroy_avp_list_unsafe(&dead_cell->user_avps_to); 254 if(dead_cell->uri_avps_from) 255 destroy_avp_list_unsafe(&dead_cell->uri_avps_from); 256 if(dead_cell->uri_avps_to) 257 destroy_avp_list_unsafe(&dead_cell->uri_avps_to); 258 if(dead_cell->xavps_list) 259 xavp_destroy_list_unsafe(&dead_cell->xavps_list); (gdb) p *dlg No symbol "dlg" in current context. (gdb) p *msg No symbol "msg" in current context. (gdb) ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2620

2 5

[kamailio/kamailio] DMQ memory leak with dmq_bcast_message function (#2600)
by jklingenmeyer 26 Mar '21

26 Mar '21

### Description We noticed a PKG memory leak when using DMQ module's function _dmq_bcast_message_ . ### Troubleshooting #### Reproduction Issue can be reproduced with configuration below. * 3 Kamailio nodes each one listening on dedicated port 5070 for DMQ on their private IP address. * A dns name _[KAMAILIO_DNS]_ resolving these 3 nodes: ``` # dig +short A [KAMAILIO_DNS] 10.234.97.169 10.234.97.170 10.234.92.126 ``` DMQ module configured as below (example for node 1) ``` loadmodule "dmq.so" ... modparam("dmq", "server_address", "sip:10.234.97.169:5070") modparam("dmq", "notification_address", "sip:[KAMAILIO_DNS]:5070") modparam("dmq", "ping_interval", 10) modparam("dmq", "multi_notify", 1) ``` Each time an INVITE comes in, we use function below to broadcast custom message to all of the nodes: ``` ... if(is_method("INVITE")) { dmq_bcast_message("invitenotification", "invite received", "text/plain"); } ... ``` This custom message is handled as below: ``` request_route { ... if(is_method("KDMQ")) { if($Rp == 5070) route(DMQHANDLE); else drop; } ... } ... route[DMQHANDLE] { if($tU == "invitenotification") { # Doing some additional stuff here, but not the cause of the leak send_reply("200", "OK"); } else { dmq_handle_message(); } } ``` Using **sipp** to send lots of messages, we can easily notice the free PKG memory decreasing over time (using `kamcmd pkg.stats`) #### Debugging Data Processes impacted by the leak are the ones processing SIP messages. In case of TCP, it is one of the tcp receivers. When doing a dump of such processes with command below: ``` kamcmd cfg.set_now_int core mem_dump_pkg [PID] ``` Results are full of records like these ones: ``` ALERT: qm_status: alloc'd from core: core/parser/parse_from.c: parse_from_header(63) ALERT: qm_status: alloc'd from core: core/parser/parse_addr_spec.c: parse_to_param(285) ``` We are sure that the leak is generated by this DMQ broadcast function: we isolated it and noticed no leaks when removing it from a basic script configuration. We tried different configurations: * disabling multi_notify => memory leak still present * using an IP address instead of the DNS name => memory leak still present Valgrind did not help us to find out more precisely where the issue in the code could be located. ### Possible Solutions Would a _free_ of _msg->from->parsed_ be missing somewhere in DMQ code? Behavior looks very similar to https://github.com/kamailio/kamailio/pull/59 ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.3.7 (x86_64/linux) c16b3f-dirty flags: , EXTRA_DEBUGUSE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, TIMER_DEBUG, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ``` * **Operating System**: ``` Debian 9.13 under docker Linux 4.9.0-9-amd64 ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2600

2 4

[kamailio/kamailio] Core dumps possibly related to #2616 or http_async_query (#2632)
by Anthony Messina 23 Mar '21

23 Mar '21

### Description When working atop the 5.4 branch patched with `--no-atexit` option from https://github.com/kamailio/kamailio/issues/2616#issuecomment-771811762 applied, I've been testing the use of http_async_query to pass out MESSAGE requests to selected destinations to an API via HTTPS. I experienced the following core dumps during the time where a higher number (may 10 or so) of these async queries may have been happening around the same time. I am not sure however how to interpret these and they may have had nothing to do with #2616. Of note for process `23694`, the logs spewed `INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table` thousands of times, spiking CPU until Kamailio finally quit with sig 11. #### Debugging Data For core dump of process `2193`: ``` #0 0x00007f367f64ea23 in free_cell_helper (dead_cell=0x7f3683d34b48, silent=0, fname=0x7f367f770902 "timer.c", fline=643) at h_table.c:186 b = 0x7f367f64c26d <futex_release+29> "\211E\374\203}\374\002\017\224\300\017\266\300H\205\300t6H\213E\350H\203\354\bj" i = 1 rpl = 0x7ffd51f7fd40 tt = 0x7ffd51f7fd60 foo = 0x0 cbs = 0x0 cbs_tmp = 0x7f3680154a20 __func__ = "free_cell_helper" #1 0x00007f367f71b738 in wait_handler (ti=2051374262, wait_tl=0x7f3683d34bd0, data=0x7f3683d34b48) at timer.c:643 p_cell = 0x7f3683d34b48 ret = 2143519712 unlinked = 0 rcount = 1 __func__ = "wait_handler" #2 0x00000000006ae985 in timer_list_expire (t=2051374262, h=0x7f367fc7c4c0, slow_l=0x7f367fc7e398, slow_mark=16842) at core/timer.c:857 tl = 0x7f3683d34bd0 ret = 32566 #3 0x00000000006aee48 in timer_handler () at core/timer.c:922 saved_ticks = 2051374262 run_slow_timer = 0 i = 458 __func__ = "timer_handler" #4 0x00000000006af30a in timer_main () at core/timer.c:961 No locals. #5 0x000000000042c59c in main_loop () at main.c:1769 i = 2 pid = 0 si = 0x0 si_desc = "udp receiver child=1 sock=[2603:300a:134:50e0::3]:5060\000\000\300\261ʈ6\177\000\000\360\005G\210\066\177\000\000Z\262ʈ6\177\000\000\060\000\000\000\060\000\000\000\b\001\370Q\375\177\000\000 \000\370Q\375\177\000\000\000\035\064\371\364\245\242.\350\301\201\000\000\000\000\000\270\251\206\210\066\177\000" nrprocs = 2 woneinit = 1 __func__ = "main_loop" #6 0x0000000000435d22 in main (argc=8, argv=0x7ffd51f80648) at main.c:2876 cfg_stream = 0x19e5120 c = -1 r = 0 tmp = 0x7ffd51f81ee5 "" tmp_len = 896 port = 896 proto = 896 ahost = 0x0 aport = 0 options = 0x7f3de8 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 504719050 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x0 p = 0xc2 <error: Cannot access memory at address 0xc2> st = {st_dev = 26, st_ino = 1205, st_nlink = 2, st_mode = 16872, st_uid = 985, st_gid = 983, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1612794079, tv_nsec = 14695130}, st_mtim = {tv_sec = 1612794079, tv_nsec = 14695130}, st_ctim = {tv_sec = 1612794079, tv_nsec = 14695130}, __glibc_reserved = {0, 0, 0}} tbuf = "@\002\370Q\375\177\000\000\000\000\000\000\000\000\000\000@\002\370Q\375\177", '\000' <repeats 18 times>, "\260\067\361\210\066\177\000\000\350\357\363\210\066\177\000\000\b\005\364\210\066\177\000\000\340\071\361\210\066\177\000\000\025\257\362\210\066\177\000\000$V\273\210\066\177\000\000\354k\363\210\066\177\000\000\336k\363\210\066\177\000\000\205\317c\t\000\000\000\000\300C\360\210\066\177\000\000߯\362\210\066\177\000\000\000\000\000\000\254\202\226\006\334@\273\210\066\177\000\000\000\000\000\000\000\000\000\000\300C\360\210\066\177\000\000\001\000\000\000\000\000\000\000\005\215.\201\267e\325\000\240\001\364\210\066\177\000\000\370\377\377\377\377\377\377\377\240\001\364\210\066\177\000\000R"... option_index = 11 long_options = {{name = 0x7f62a6 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x7f1523 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x7f62ab "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x7f62b1 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7f62b7 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x7f62c0 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, { name = 0x7f62ca "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7f62d4 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x7f62df "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7f62e8 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x7f62f3 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x7f62f9 "no-atexit", has_arg = 0, flag = 0x0, val = 1033}, { name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" b = 0x7f367f64c26d <futex_release+29> "\211E\374\203}\374\002\017\224\300\017\266\300H\205\300t6H\213E\350H\203\354\bj" i = 1 rpl = 0x7ffd51f7fd40 tt = 0x7ffd51f7fd60 foo = 0x0 cbs = 0x0 cbs_tmp = 0x7f3680154a20 __func__ = "free_cell_helper" 181 /* It is safer to release the shm memory lock 182 * otherwise the release function must to be aware of 183 * the lock state (Miklos) 184 */ 185 shm_global_unlock(); 186 cbs_tmp->release(cbs_tmp->param); 187 shm_global_lock(); 188 } 189 shm_free_unsafe(cbs_tmp); 190 } ``` For core dump of process `23694`: ``` #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:96 No locals. #1 0x00007f83502f94f8 in __vfprintf_internal (s=s@entry=0x143c6d0, format=format@entry=0x7f8345c7ba08 "%s: %.*s%s%s%shandle %p returned error %d: %s\n", ap=ap@entry=0x7ffc27d97d10, mode_flags=mode_flags@entry=0) at vfprintf-internal.c:1647 len = <optimized out> step0_jumps = {0, 1757, 1653, 3485, 3381, 4069, 2733, 2893, 3685, 1813, 4405, 4565, 3589, 4549, 4493, 2845, 4285, 3989, 3285, 3053, 1173, 1397, 2053, 1973, 1933, 757, 3781, 549, 553, 4181} space = <optimized out> is_short = <optimized out> use_outdigits = 0 outc = <optimized out> step1_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 1813, 4405, 4565, 3589, 4549, 4493, 2845, 4285, 3989, 3285, 3053, 1173, 1397, 2053, 1973, 1933, 757, 3781, 549, 553, 0} group = 0 prec = -1 step2_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4405, 4565, 3589, 4549, 4493, 2845, 4285, 3989, 3285, 3053, 1173, 1397, 2053, 1973, 1933, 757, 3781, 549, 553, 0} string = 0xb8 <error: Cannot access memory at address 0xb8> left = 0 is_long_double = <optimized out> width = 0 signed_number = <optimized out> step3a_jumps = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4309, 0, 0, 0, 4493, 2845, 4285, 3989, 3285, 0, 0, 0, 0, 1973, 0, 0, 0, 0, 0, 0} alt = <optimized out> showsign = 0 is_long = 0 is_char = <optimized out> pad = <optimized out> step3b_jumps = {0 <repeats 11 times>, 3589, 0, 0, 4493, 2845, 4285, 3989, 3285, 3053, 1173, 1397, 2053, 1973, 1933, 757, 3781, 0, 0, 0} step4_jumps = {0 <repeats 14 times>, 4493, 2845, 4285, 3989, 3285, 3053, 1173, 1397, 2053, 1973, 1933, 757, 3781, 0, 0, 0} args_value = <optimized out> is_negative = <optimized out> number = {longlong = <optimized out>, word = <optimized out>} base = <optimized out> the_arg = {pa_wchar = 1698128436 L'\x65376234', pa_int = 1698128436, pa_long_int = 4048843148828828212, pa_long_long_int = 4048843148828828212, pa_u_int = 1698128436, pa_u_long_int = 4048843148828828212, pa_u_long_long_int = 4048843148828828212, pa_double = 4.8137781308181096e-38, pa_long_double = <invalid float value>, pa_float128 = 4.25777496576548470393424945528503408e-3201, pa_string = 0x3830616465376234 <error: Cannot access memory at address 0x3830616465376234>, pa_wstring = 0x3830616465376234 <error: Cannot access memory at address 0x3830616465376234>, pa_pointer = 0x3830616465376234, pa_user = 0x3830616465376234} spec = 115 's' _buffer = {__routine = 0x7ffc27d977b0, __arg = 0x7f8345c75daf, __canceltype = 668563760, __prev = 0x7f835030a3ba <__vsnprintf_internal+170>} _avail = <optimized out> thousands_sep = 0x0 grouping = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff> done = 106 f = 0x7f8345c7ba34 "s\n" lead_str_end = 0x7f8345c7ba08 "%s: %.*s%s%s%shandle %p returned error %d: %s\n" end_of_spec = <optimized out> work_buffer = "`z\331'\374\177\000\000nz\331'\374\177\000\000sz\331'\374\177\000\000`z\331'\374\177\000\000sz\331'\374\177", '\000' <repeats 46 times>, "\200\000\000\000\000\027\021ю\203w\026", '\000' <repeats 24 times>, "\220PcO\203\177\000\000\377\377\377\377\377\377\377\377", '\000' <repeats 16 times>, "\035GGO\203\177\000\000\377\377\377\377\374\177\000\000v\037CO\203\177\000\000H\241(P\203\177\000\000 \020EP\203\177\000\000\000\000\000\000\000\000\000\000u"... workend = 0x7ffc27d97bb8 "" ap_save = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7ffc27d97df0, reg_save_area = 0x7ffc27d97d30}} nspecs_done = 7 save_errno = 11 readonly_format = 0 do_longlong_number = <optimized out> __result = <optimized out> #2 0x00007f8350386da3 in __vsyslog_internal (pri=<optimized out>, fmt=0x7f8345c7ba08 "%s: %.*s%s%s%shandle %p returned error %d: %s\n", ap=0x7ffc27d97d10, mode_flags=0) at ../misc/syslog.c:233 now_tm = {tm_sec = 28, tm_min = 59, tm_hour = 12, tm_mday = 8, tm_mon = 1, tm_year = 121, tm_wday = 1, tm_yday = 38, tm_isdst = 0, tm_gmtoff = -21600, tm_zone = 0x143ead0 "CST"} now = 1612810768 fd = <optimized out> f = 0x143c6d0 buf = 0x0 bufsize = 0 msgoff = 20 saved_errno = <optimized out> failbuf = "\017\000\000\000\000\000\000\000\230\323PK\203\177\000\000\000\000\000\000\000\000\000\000D}\331", <incomplete sequence \374> clarg = {buf = <optimized out>, oldaction = <optimized out>} #3 0x00007f835038725a in __syslog (pri=<optimized out>, fmt=<optimized out>) at ../misc/syslog.c:117 ap = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7ffc27d97e18, reg_save_area = 0x7ffc27d97d30}} #4 0x00007f8345c714bf in check_multi_info (g=0x7f834afb1358) at http_multi.c:583 __llevel = -1 eff_url = 0x7f834b1fd168 "https://messinet.com/api/kamailio/message" msg = 0x7f834b50d400 msgs_left = 0 easy = 0x7f834b50d398 res = CURLE_WRITE_ERROR cell = 0x0 __func__ = "check_multi_info" #5 0x00007f8345c67d73 in event_cb (fd=15, kind=2, userp=0x7f834b7eda08) at http_multi.c:145 g = 0x7f834afb1358 rc = CURLM_OK easy = 0x7f834b7eda08 cell = 0x7f834b27ce90 __func__ = "event_cb" action = 1 #6 0x00007f8345b65c4a in event_persist_closure (ev=<optimized out>, base=0x1612440) at event.c:1580 evcb_callback = <optimized out> evcb_fd = <optimized out> evcb_res = 2 evcb_arg = 0x7f834b7eda08 evcb_callback = <optimized out> evcb_fd = <optimized out> evcb_res = <optimized out> evcb_arg = <optimized out> __func__ = {<optimized out> <repeats 22 times>} run_at = {tv_sec = <optimized out>, tv_usec = <optimized out>} relative_to = {tv_sec = <optimized out>, tv_usec = <optimized out>} delay = {tv_sec = <optimized out>, tv_usec = <optimized out>} now = {tv_sec = <optimized out>, tv_usec = <optimized out>} usec_mask = <optimized out> #7 event_process_active_single_queue (base=base@entry=0x1612440, activeq=0x16087e0, max_to_process=max_to_process@entry=2147483647, endtime=endtime@entry=0x0) at event.c:1639 ev = <optimized out> evcb_selfcb = <optimized out> evcb = <optimized out> count = 1 __func__ = "event_process_active_single_queue" #8 0x00007f8345b675d7 in event_process_active (base=0x1612440) at event.c:1738 activeq = <optimized out> i = 0 c = 0 tv = {tv_sec = 16697, tv_usec = 733811} maxcb = 2147483647 endtime = 0x0 limit_after_prio = 2147483647 activeq = <optimized out> i = <optimized out> c = <optimized out> endtime = <optimized out> tv = {tv_sec = <optimized out>, tv_usec = <optimized out>} maxcb = <optimized out> limit_after_prio = <optimized out> done = <optimized out> #9 event_base_loop (base=0x1612440, flags=0) at event.c:1961 n = <optimized out> evsel = 0x7f8345b97c80 <epollops> tv = {tv_sec = 0, tv_usec = 0} tv_p = <optimized out> res = <optimized out> done = 0 retval = 0 __func__ = "event_base_loop" #10 0x00007f8345c4550b in async_http_run_worker (worker=0x7f8347831378) at async_http.c:92 No locals. #11 0x00007f8345c5a278 in child_init (rank=0) at http_async_client_mod.c:368 pid = 0 i = 0 __func__ = "child_init" #12 0x000000000062148b in init_mod_child (m=0x7f834fb539d8, rank=0) at core/sr_module.c:780 __func__ = "init_mod_child" #13 0x00000000006210fa in init_mod_child (m=0x7f834fb545b8, rank=0) at core/sr_module.c:776 __func__ = "init_mod_child" #14 0x00000000006210fa in init_mod_child (m=0x7f834fb54d58, rank=0) at core/sr_module.c:776 __func__ = "init_mod_child" #15 0x00000000006210fa in init_mod_child (m=0x7f834fb55128, rank=0) at core/sr_module.c:776 __func__ = "init_mod_child" #16 0x00000000006210fa in init_mod_child (m=0x7f834fb555e0, rank=0) at core/sr_module.c:776 __func__ = "init_mod_child" #17 0x00000000006210fa in init_mod_child (m=0x7f834fb55ae8, rank=0) at core/sr_module.c:776 __func__ = "init_mod_child" #18 0x0000000000621c4a in init_child (rank=0) at core/sr_module.c:825 ret = 1341536656 type = 0x83d00b "PROC_MAIN" __func__ = "init_child" #19 0x000000000042c8a2 in main_loop () at main.c:1779 i = 2 pid = 23675 si = 0x0 si_desc = "udp receiver child=1 sock=[2603:300a:134:50e0::3]:5060\000\000\300q8P\203\177\000\000\360ŴO\203\177\000\000Zr8P\203\177\000\000\060\000\000\000\060\000\000\000\270\210\331'\374\177\000\000Ї\331'\374\177\000\000\000\027\021ю\203w\026\350\301\201\000\000\000\000\000\270i\364O\203\177\000" nrprocs = 2 woneinit = 1 __func__ = "main_loop" #20 0x0000000000435d22 in main (argc=8, argv=0x7ffc27d98df8) at main.c:2876 cfg_stream = 0x1337120 c = -1 r = 0 tmp = 0x7ffc27d9aee4 "" tmp_len = 896 port = 896 proto = 896 ahost = 0x0 aport = 0 options = 0x7f3de8 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 3012900158 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x0 p = 0xc2 <error: Cannot access memory at address 0xc2> st = {st_dev = 26, st_ino = 1205, st_nlink = 2, st_mode = 16872, st_uid = 985, st_gid = 983, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1612794079, tv_nsec = 14695130}, st_mtim = {tv_sec = 1612810438, tv_nsec = 182128841}, st_ctim = {tv_sec = 1612810438, tv_nsec = 182128841}, __glibc_reserved = {0, 0, 0}} tbuf = "\360\211\331'\374\177\000\000\000\000\000\000\000\000\000\000\360\211\331'\374\177", '\000' <repeats 18 times>, "\260\367^P\203\177\000\000\350\257aP\203\177\000\000\b\305aP\203\177\000\000\340\371^P\203\177\000\000\025o`P\203\177\000\000$\026)P\203\177\000\000\354+aP\203\177\000\000\336+aP\203\177\000\000\205\317c\t\000\000\000\000\300\003^P\203\177\000\000\337o`P\203\177\000\000\000\000\000\000\254\202\226\006\334\000)P\203\177\000\000\000\000\000\000\000\000\000\000\300\003^P\203\177\000\000\001\000\000\000\000\000\000\000\360`\207\272ޟ\325\000\240\301aP\203\177\000\000\370\377\377\377\377\377\377\377\240\301aP\203\177\000\000R"... option_index = 11 long_options = {{name = 0x7f62a6 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x7f1523 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x7f62ab "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x7f62b1 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x7f62b7 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x7f62c0 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x7f62ca "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x7f62d4 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x7f62df "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x7f62e8 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x7f62f3 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x7f62f9 "no-atexit", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" No locals. 91 92 .p2align 4 93 L(cros_page_boundary): 94 andl $(VEC_SIZE - 1), %ecx 95 andq $-VEC_SIZE, %rdi 96 VPCMPEQ (%rdi), %ymm0, %ymm1 97 vpmovmskb %ymm1, %eax 98 /* Remove the leading bytes. */ 99 sarl %cl, %eax 100 testl %eax, %eax ``` #### Log Messages Log for process `2193`: ``` Feb 08 12:53:31 kamailio[2216]: [HTTP_REPLY] MESSAGE via HTTP_API succeeded: 202, HTTP/2 202 ^M date: Mon, 08 Feb 2021 18:53:31 GMT^M server: Apache/2.4.46^M strict-transport-security: max-age=15552000; includeSubDomains^M content-length: 46^M vary: User-Agent^M content-type: application/json; charset=utf-8^M ^M {"result": {"code": 202, "title": "Accepted"}} Feb 08 12:53:31 kamailio[2216]: [HTTP_REPLY] MESSAGE via HTTP_API succeeded: 202, HTTP/2 202 ^M date: Mon, 08 Feb 2021 18:53:31 GMT^M server: Apache/2.4.46^M strict-transport-security: max-age=15552000; includeSubDomains^M content-length: 46^M vary: User-Agent^M content-type: application/json; charset=utf-8^M ^M {"result": {"code": 202, "title": "Accepted"}} Feb 08 12:53:55 kamailio[2216]: [HTTP_REPLY] MESSAGE via HTTP_API succeeded: 202, HTTP/2 202 ^M date: Mon, 08 Feb 2021 18:53:55 GMT^M server: Apache/2.4.46^M strict-transport-security: max-age=15552000; includeSubDomains^M content-length: 46^M vary: User-Agent^M content-type: application/json; charset=utf-8^M ^M {"result": {"code": 202, "title": "Accepted"}} Feb 08 12:53:58 kamailio[1957]: ALERT: <core> [main.c:784]: handle_sigs(): child process 2193 exited by a signal 11 Feb 08 12:53:58 kamailio[2227]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 34 Feb 08 12:53:58 kamailio[1957]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated Feb 08 12:53:58 kamailio[1957]: INFO: <core> [main.c:810]: handle_sigs(): terminating due to SIGCHLD Feb 08 12:53:58 kamailio[2168]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2165]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2166]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2170]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2172]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2180]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2190]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2174]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2187]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2177]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2221]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2227]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2184]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2195]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2216]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2224]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2219]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[2206]: INFO: <core> [main.c:873]: sig_usr(): signal 15 received Feb 08 12:53:58 kamailio[1957]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Feb 08 12:53:58 systemd[1]: kamailio.service: Main process exited, code=exited, status=1/FAILURE Feb 08 12:53:58 systemd[1]: kamailio.service: Failed with result 'exit-code'. Feb 08 12:53:58 systemd[1]: kamailio.service: Consumed 10.011s CPU time. Feb 08 12:54:28 systemd[1]: kamailio.service: Scheduled restart job, restart counter is at 1. Feb 08 12:54:28 systemd[1]: Stopped Kamailio SIP Server. ``` Log for process `23694`: ``` Feb 08 12:59:09 kamailio[23694]: [HTTP_REPLY] MESSAGE via HTTP_API succeeded: 202, HTTP/2 202 ^M date: Mon, 08 Feb 2021 18:59:09 GMT^M server: Apache/2.4.46^M strict-transport-security: max-age=15552000; includeSubDomains^M content-length: 46^M vary: User-Agent^M content-type: application/json; charset=utf-8^M ^M {"result": {"code": 202, "title": "Accepted"}} Feb 08 12:59:09 kamailio[23694]: [HTTP_REPLY] MESSAGE via HTTP_API succeeded: 202, HTTP/2 202 ^M date: Mon, 08 Feb 2021 18:59:09 GMT^M server: Apache/2.4.46^M strict-transport-security: max-age=15552000; includeSubDomains^M content-length: 46^M vary: User-Agent^M content-type: application/json; charset=utf-8^M ^M {"result": {"code": 202, "title": "Accepted"}} Feb 08 12:59:13 kamailio[23694]: [HTTP_REPLY] MESSAGE via HTTP_API succeeded: 202, HTTP/2 202 ^M date: Mon, 08 Feb 2021 18:59:13 GMT^M server: Apache/2.4.46^M strict-transport-security: max-age=15552000; includeSubDomains^M content-length: 46^M vary: User-Agent^M content-type: application/json; charset=utf-8^M ^M {"result": {"code": 202, "title": "Accepted"}} Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:13 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table ... ... Feb 08 12:59:14 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:14 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:14 kamailio[23694]: INFO: http_async_client [http_multi.c:87]: event_cb(): Cell for handler 0x7f834b7eda08 not found in table Feb 08 12:59:28 kamailio[23694]: ERROR: http_async_client [http_multi.c:253]: write_cb(): Cell for handler 0x7f834b50d398 not found in table Feb 08 12:59:29 kamailio[23709]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 43 Feb 08 12:59:29 kamailio[23633]: ALERT: <core> [main.c:784]: handle_sigs(): child process 23694 exited by a signal 11 Feb 08 12:59:29 kamailio[23633]: ALERT: <core> [main.c:787]: handle_sigs(): core was generated Feb 08 12:59:29 systemd[1]: kamailio.service: Main process exited, code=exited, status=1/FAILURE Feb 08 12:59:29 systemd[1]: kamailio.service: Failed with result 'exit-code'. Feb 08 12:59:29 systemd[1]: kamailio.service: Consumed 11.523s CPU time. Feb 08 12:59:59 systemd[1]: kamailio.service: Scheduled restart job, restart counter is at 2. Feb 08 12:59:59 systemd[1]: Stopped Kamailio SIP Server. ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.4.3-6.gitdbe358d2d0.fc33.1 (x86_64/linux) e19ae3 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: e19ae3 compiled on 00:00:00 Feb 5 2021 with gcc 10.2.1 ``` * **Operating System**: ``` Fedora 33 Linux 5.10.13-200.fc33.x86_64 #1 SMP Thu Feb 4 14:54:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2632

5 20

Roadmap to the next major release - v5.5.0
by Daniel-Constantin Mierla 15 Mar '21

15 Mar '21

Hello, it is the time to plan a bit the road to the next major release, to be versioned 5.5.0. The 5.4.0 was release by end of July 2020, therefore we are approaching the end of our usual development cycle, also during the last online devel meeting we considered the 2nd part of spring 2021 as a target time frame for 5.5. To narrow it down, I would propose to freeze the development at the end of March 2021, test during April and maybe beginning of May, then release v5.5.0. So far we have a lot of development to existing components, by the freeze date I expect 3-5 new modules to be in the repo as well. If anyone wants a different time line towards 5.5.0, let's discuss and choose the one that suits most of the developers. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla

1 1

[kamailio/kamailio] Issue with new memory-only presence feature in 5.4.3 (#2642)
by Joe Mordica 12 Mar '21

12 Mar '21

### Description I've been trying the new in-memory only presence feature in 5.4.x but have run into an issue: ``` ERROR: presence [presence_dmq.c:109]: pres_dmq_init_proc(): dmq_worker_init: database not bound kamailio[8404]: segfault at 0 ip 00007f4f8419c4d7 sp 00007ffd68ef0130 error 4 in presence.so[7f4f8418d000+fe000] CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 31 ALERT: <core> [main.c:777]: handle_sigs(): child process 8411 exited by a signal 11 ``` I have this set `modparam("presence", "publ_cache", 2)` but had to comment it out in order to prevent kamailio from crashing. I have reverted back to using mysql for storing presentity records for now. ### Troubleshooting #### Reproduction Starting kamailio with these mod params can re-produce the issue. ``` #!ifdef WITH_PRESENCE # ----- presence params ----- modparam("presence", "db_url", DBURL) modparam("presence", "server_address", "sip:EXTERNAL_LISTEN_IP:EXTERNAL_UDP_PORT") modparam("presence", "subs_db_mode", 0) modparam("presence", "publ_cache", 2) modparam("presence", "clean_period", 40) modparam("presence", "max_expires", 3600010) modparam("presence", "enable_dmq", 1) # ----- presence_xml params ----- modparam("presence_xml", "db_url", DBURL) modparam("presence_xml", "force_active", 1) # ----- presence_dialoginfo params ----- modparam("presence_dialoginfo", "force_dummy_dialog", 1) #!endif ``` #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.4.3 (x86_64/linux) e19ae3 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: e19ae3 compiled on 18:17:25 Dec 14 2020 with gcc 4.8.5 ``` * **Operating System**:  ``` CentOS 7 - Linux hostname 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2642

2 8

[kamailio/kamailio] lookup_to_dset should be documented (#2623)
by Alessio Garzi 12 Mar '21

12 Mar '21

The function lookup_to_dset() is a config command implemented inside the registrar module. https://github.com/kamailio/kamailio/blob/351efd29d332703e79104a106ade08c9d… As you can see from the link above, It triggers w_lookup_to_dset() and it ends up calling lookup_helper() with the mode flag set to zero that causes lookup_helper() to not overwrite the request uri (and destination uri if it's the case). For me it's worth documenting lookup_to_dset() inside modules/registrar/README file, this function it was very useful to me and I found out about it only digging into the code. Thanks -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2623

2 2

[kamailio/kamailio] dns_int_match_ip is broken (#2645)
by Nathan 09 Mar '21

09 Mar '21

### Description `dns_int_match_ip` is broken on 5.3.0 and above ### Troubleshooting #### Reproduction Try this dialplan: ``` if (dns_int_match_ip('dns.google', '8.8.8.8')) { xlog("L_INFO", "OK dns-ip match with dns_int_match_ip"); } else { xlog("L_ERR", "FAIL dns-ip match with dns_int_match_ip"); } if (dns_int_match_ip('100.100.100.100', '8.8.8.8')) { xlog("L_ERR", "FAIL dns_int_match_ip on 2 ip's"); } else { xlog("L_INFO", "OK dns_int_match_ip on 2 ip's"); } ``` On 5.2 releases, both checks succeed. On 5.3 and up, both fail. #### Debugging Data I've traced down the problem to `str2ip`. In 5.2, this is a `static inline` function defined in the header file `resolve.h`. Therefore, the returned `ip` structure is allocated *once per compilation unit* - ie. `ipops_mod.c` and `dns_cache.c` both have their own versions of the variable. Since fb75e90549a (5.3 and up) this function is defined in it's own compilation unit (`resolve.c`) and therefore shared by all callers. See: https://stackoverflow.com/questions/185624/static-variables-in-an-inlined-f… #### Log Messages n/a #### SIP Traffic n/a ### Possible Solutions - Have `ki_dns_sys_match_ip` make a local copy of the return value of `str2ip` - Move `str2ip` back to a header file - Refactor `str2ip` to take a pointer to an output struct ### Additional Information In 5.3, this is what happens: ``` # - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable # - resolvehost will call dns_a_get_he, which calls str2ip on dns.google.com, zeroing out the static variable # - (dns_cache_do_request will call str2ip on dns.google.com, zeroing out the static variable again) # - resolvehost queries DNS # - the resolved IP's will be compared to the zero'd out struct dns_int_match_ip('dns.google', '8.8.8.8') == false # - ki_dns_int_match_ip will call str2ip on 8.8.8.8, filling the static variable # - resolvehost will call dns_a_get_he, which calls str2ip on 100.100.100.100, overwriting the static variable # - the static variable will be compared to itself dns_int_match_ip('100.100.100.100', '8.8.8.8') == true ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/2645

2 3

← Newer
1
...
7
8
9
10
11
12
13
...
26
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2021