sr-dev

sr-dev@lists.kamailio.org

25 participants
47009 discussions

[kamailio/kamailio] tm: use bitwise check for REQ_ERR_DELAYED in t_unref() (PR #4644)
by Norm Brandinger 16 Mar '26

16 Mar '26

Fixes #4503. ### Problem Transactions leak when `drop;` executes in a `branch_route` and modules like `pua_dialoginfo` are loaded. The leaked transactions persist indefinitely in shared memory — no final reply is sent, no timer fires, and `wait_handler()` never frees the cell. ### Cause `set_kr()` accumulates flags with `|=`, but the first cleanup check in `t_unref()` uses exact equality: ```c if(unlikely(kr == REQ_ERR_DELAYED)) { // fails when other flags are set ``` When `pua_dialoginfo` processes an INVITE, it calls `dialog_publish_multi()` inline during `DLGCB_CREATED`, which goes through `pua_send_publish()` → `tmb.t_request()` → `t_uac_prepare()` → `set_kr(REQ_FWDED)`. If the INVITE's `branch_route` then calls `drop;`, `t_relay_to()` ORs in `REQ_ERR_DELAYED`, making `_tm_kr = REQ_FWDED | REQ_ERR_DELAYED` (17). In `t_unref()`: - Check 1: `17 == 16` → false - Check 2: `17 == 0` → false - Check 3: `(17 & 16)` true, but `(17 & ~(4|2|16|1))` = 0 → false All three checks fail. The transaction is orphaned. This affects any module that calls `t_request()` or `t_uac_prepare()` inline during INVITE processing — `pua_dialoginfo` is one common example. ### Fix Change the check from exact equality to a bitwise test: ```c - if(unlikely(kr == REQ_ERR_DELAYED)) { + if(unlikely(kr & REQ_ERR_DELAYED)) { ``` The delayed-reply handler now fires whenever `REQ_ERR_DELAYED` is present, regardless of other flags accumulated by `set_kr()`. This is safe because: - `REQ_ERR_DELAYED` is only set in `t_relay_to()` when `t_forward_nonack()` fails and the delayed-reply path is chosen — it is never set spuriously. - `kill_transaction()` already handles the case where a final reply was previously sent (`FL_FINAL_REPLY` check → `t_release_transaction()`). The existing check-3 fallback (lines 2077-2084) becomes unreachable after this change but is harmless to leave in place. ### Workaround On 6.1+ where `delayed_reply` is a runtime modparam, setting `modparam("tm", "delayed_reply", 0)` avoids the vulnerable code path. On ≤ 6.0.x, `TM_DELAYED_REPLY` is a compile-time `#define` (always on) and there is no workaround — only this patch fixes the leak. ### Test results Ten-scenario matrix across 6.0.3, 6.1.0, and 6.2.0-dev0 master. 1000 INVITEs per run, `fr_timer=5000`, `branch_route` with unconditional `drop;`. Contamination triggered naturally by loading `dialog` + `pua` + `pua_dialoginfo` — no source modification beyond this patch. | # | Version | Patch | `delayed_reply` | current | 5xx | SHM delta | Verdict | |---|---------|-------|:---------------:|--------:|----:|----------:|---------| | 1 | 6.0.3 | no | x | 431 | 0 | +7,150,272 | **LEAK** | | 2 | 6.0.3 | yes | x | 0 | 353 | 0 | OK | | 3 | 6.1.0 | no | 1 | 431 | 0 | +7,287,200 | **LEAK** | | 4 | 6.1.0 | no | 0 | 0 | 375 | 0 | OK | | 5 | 6.1.0 | yes | 1 | 0 | 407 | 0 | OK | | 6 | 6.1.0 | yes | 0 | 0 | 336 | 0 | OK | | 7 | 6.2.0-dev0 | no | 1 | 446 | 0 | +7,770,288 | **LEAK** | | 8 | 6.2.0-dev0 | no | 0 | 0 | 461 | 0 | OK | | 9 | 6.2.0-dev0 | yes | 1 | 0 | 448 | 0 | OK | | 10 | 6.2.0-dev0 | yes | 0 | 0 | 448 | 0 | OK | `delayed_reply` = x: not available as a modparam (compile-time, always on). `current`: transactions remaining in hash table after test. `5xx`: 500 replies sent by the delayed-reply handler (nonzero = cleanup ran). --- *Note: AI tooling was used to assist with the code analysis, reproduction, and test automation for this issue. All diagnosis, testing, and review was supervised by @NormB — the AI did not operate autonomously. The root cause identification, fix selection, and validation were guided and verified at each step.* You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4644 -- Commit Summary -- * tm: use bitwise check for REQ_ERR_DELAYED in t_unref() -- File Changes -- M src/modules/tm/t_lookup.c (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4644.patch https://github.com/kamailio/kamailio/pull/4644.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4644 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4644(a)github.com>

2 3

[kamailio/kamailio] Sanity add some Via related validations (PR #4643)
by Xenofon Karamanos 16 Mar '26

16 Mar '26

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] 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 - [x] 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 #XXXX (replace XXXX with an open issue number) #### Description  This PR add two validation tests related to VIA. 1. Check if VIA is present through the `required_headers` function. the docs suggest to check for it but code does not (not in this function anyway) (considered a bug?) Another note though is that sanity module may be not really acting on this at all due to some sanity check found in (https://github.com/kamailio/kamailio/blob/41c30c244ca0ca8b3c201e0c02602b255…) and that kamailio cfg will drop the msg much earlier 2. Check if branch paramater is present in the Via header which is mandatory according to RFC. (new feature) Also increase a dbg to err log and check for host len more stricly. 0-len host is not valid. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4643 -- Commit Summary -- * sanity: Add Via header to required_headers check * sanity: Add branch sanity check for Via header * sanity: Increase log to error * sanity: Check host len more strictly -- File Changes -- M src/modules/sanity/sanity.c (16) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4643.patch https://github.com/kamailio/kamailio/pull/4643.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4643 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4643(a)github.com>

3 4

[kamailio/kamailio] Potential SHM memory leak in pua_dialoginfo / pua modules ? (Issue #4503)
by Alessio Garzi 16 Mar '26

16 Mar '26

Ozzyboshi created an issue (kamailio/kamailio#4503) Hello, on my Kamailio installation I am experiencing a significant memory leak in SHM. Here are the details of my system: ``` version: kamailio 6.0.3 (x86_64/linux) flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, NO_SIG_DEBUG, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, 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_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS: 1024 MAX_RECV_BUFFER_SIZE: 262144 MAX_SEND_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 compiled with gcc 14.2.0 ``` The memory leak appears only when the presence feature is enabled. When presence is active, Kamailio starts running dialog_publish(), whose code is here: https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… This function does not send the PUBLISH directly: it calls pua_send_publish(), which is a function pointer referring to the send_publish() implementation in the pua module. Then send_publish() eventually calls set_uac_req() and tmb.t_request(): https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… Digging further, tmb.t_request() maps to request() in the TM module, which calls t_uac_with_ids() and then t_uac_prepare(). Now comes the suspicious part: If I comment out the call to t_uac_prepare(), the memory leak disappears. This doesn’t necessarily mean the bug is inside t_uac_prepare(), but it’s a strong hint. t_uac_prepare() allocates a new struct cell and returns it: https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… My concern is: is this cell always freed? The matching cleanup function is free_cell(), used only here: https://github.com/kamailio/kamailio/blob/9dc160d1d2bdf0542d3d9d8ae090bb135… From what I can tell, free_cell() is called only if all these conditions are true: - dst_cell == 0 - is_ack == 1 - dst_req == 0 - In my situation no ACK is involved (Kamailio is a proxy that sends PUBLISH and immediately gets a 200 OK). Therefore, is_ack is always false meaning the free_cell() cleanup logic is skipped entirely. I tried forcing free_cell() unconditionally, but it leads to crashes, so clearly other parts of the code still rely on this structure. Does the current free_cell() logic look correct to you? Is it expected that struct cell allocated by t_uac_prepare() remains unfreed in cases where PUBLISH → 200 OK occurs without ACK? Any guidance on how to proceed or where else to look would be greatly appreciated. Thanks -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4503 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4503(a)github.com>

5 18

[kamailio/kamailio] cmake install: kamdbctl cannot create database tables (Issue #4621)
by Daniel-Constantin Mierla 16 Mar '26

16 Mar '26

miconda created an issue (kamailio/kamailio#4621) By using `cmake` to install and build, the `kamdbctl` cannot create database tables: ``` shell kamdbctl: 292: cannot open ./mysql/standard-create.sql: No such file ``` Given that cmake is used to build the deb packages, I expect that it affects installations via debs as well. I am holding releasing 6.1.1 for a bit, hoping to get this one fixed -- maybe others can help quickly. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4621 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4621(a)github.com>

3 5

[tracker] Assignee added: Assignment operators don't work
by sip-router 16 Mar '26

16 Mar '26

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A user has added themself to the list of users assigned to this task. FS#100 - Assignment operators don't work User who did this - Alex Hermann (axlh) http://sip-router.org/tracker/index.php?do=details&task_id=100 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.

9 8

git:master:1c492c47: evapi: reformat exported structures
by Daniel-Constantin Mierla 16 Mar '26

16 Mar '26

Module: kamailio Branch: master Commit: 1c492c47eab07ca39a1bba5e5f45186eeb73b3ca URL: https://github.com/kamailio/kamailio/commit/1c492c47eab07ca39a1bba5e5f45186… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2026-03-16T10:40:19+01:00 evapi: reformat exported structures --- Modified: src/modules/evapi/evapi_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/1c492c47eab07ca39a1bba5e5f45186… Patch: https://github.com/kamailio/kamailio/commit/1c492c47eab07ca39a1bba5e5f45186… --- diff --git a/src/modules/evapi/evapi_mod.c b/src/modules/evapi/evapi_mod.c index 4b6249c1c4b..51dbb04e717 100644 --- a/src/modules/evapi/evapi_mod.c +++ b/src/modules/evapi/evapi_mod.c @@ -80,15 +80,22 @@ static int fixup_free_evapi_multicast(void **param, int param_no); /* clang-format off */ static cmd_export_t cmds[] = { - {"evapi_relay", (cmd_function)w_evapi_relay, 1, fixup_vstr_all, fixup_free_vstr_all, ANY_ROUTE}, - {"evapi_async_relay", (cmd_function)w_evapi_async_relay, 1, fixup_vstr_all, fixup_free_vstr_all, REQUEST_ROUTE}, - {"evapi_multicast", (cmd_function)w_evapi_multicast, 2, fixup_evapi_multicast, fixup_free_evapi_multicast, ANY_ROUTE}, - {"evapi_async_multicast", (cmd_function)w_evapi_async_multicast, 2, fixup_evapi_multicast, fixup_free_evapi_multicast, REQUEST_ROUTE}, - {"evapi_unicast", (cmd_function)w_evapi_unicast, 2, fixup_evapi_multicast, fixup_free_evapi_multicast, ANY_ROUTE}, - {"evapi_async_unicast", (cmd_function)w_evapi_async_unicast, 2, fixup_evapi_multicast, fixup_free_evapi_multicast, REQUEST_ROUTE}, + {"evapi_relay", (cmd_function)w_evapi_relay, 1, + fixup_vstr_all, fixup_free_vstr_all, ANY_ROUTE}, + {"evapi_async_relay", (cmd_function)w_evapi_async_relay, 1, + fixup_vstr_all, fixup_free_vstr_all, REQUEST_ROUTE}, + {"evapi_multicast", (cmd_function)w_evapi_multicast, 2, + fixup_evapi_multicast, fixup_free_evapi_multicast, ANY_ROUTE}, + {"evapi_async_multicast", (cmd_function)w_evapi_async_multicast, 2, + fixup_evapi_multicast, fixup_free_evapi_multicast, REQUEST_ROUTE}, + {"evapi_unicast", (cmd_function)w_evapi_unicast, 2, + fixup_evapi_multicast, fixup_free_evapi_multicast, ANY_ROUTE}, + {"evapi_async_unicast", (cmd_function)w_evapi_async_unicast, 2, + fixup_evapi_multicast, fixup_free_evapi_multicast, REQUEST_ROUTE}, {"evapi_close", (cmd_function)w_evapi_close, 0, NULL, 0, ANY_ROUTE}, {"evapi_close", (cmd_function)w_evapi_close, 1, NULL, 0, ANY_ROUTE}, - {"evapi_set_tag", (cmd_function)w_evapi_set_tag, 1, fixup_spve_null, fixup_free_spve_null, ANY_ROUTE}, + {"evapi_set_tag", (cmd_function)w_evapi_set_tag, 1, fixup_spve_null, + fixup_free_spve_null, ANY_ROUTE}, {0, 0, 0, 0, 0, 0} }; @@ -106,7 +113,8 @@ static param_export_t params[] = { }; static pv_export_t mod_pvs[] = { - {{"evapi", (sizeof("evapi") - 1)}, PVT_OTHER, pv_get_evapi, pv_set_evapi, pv_parse_evapi_name, 0, 0, 0}, + {{"evapi", (sizeof("evapi") - 1)}, PVT_OTHER, pv_get_evapi, pv_set_evapi, + pv_parse_evapi_name, 0, 0, 0}, {{0, 0}, 0, 0, 0, 0, 0, 0, 0} }; /* clang-format on */

1 0

git:master:311157f8: tm: uac build - use bracket condtion also for length
by Daniel-Constantin Mierla 16 Mar '26

16 Mar '26

Module: kamailio Branch: master Commit: 311157f86c6707be68258df7537345cc8075f90b URL: https://github.com/kamailio/kamailio/commit/311157f86c6707be68258df7537345c… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2026-03-16T10:40:19+01:00 tm: uac build - use bracket condtion also for length --- Modified: src/modules/tm/t_msgbuilder.c --- Diff: https://github.com/kamailio/kamailio/commit/311157f86c6707be68258df7537345c… Patch: https://github.com/kamailio/kamailio/commit/311157f86c6707be68258df7537345c… --- diff --git a/src/modules/tm/t_msgbuilder.c b/src/modules/tm/t_msgbuilder.c index df3f69052db..dae57fe54ff 100644 --- a/src/modules/tm/t_msgbuilder.c +++ b/src/modules/tm/t_msgbuilder.c @@ -1554,11 +1554,9 @@ static inline char *print_to( char *w, dlg_t *dialog, struct cell *t, int bracket) { t->to_hdr.s = w; - t->to_hdr.len = - TO_LEN + dialog->rem_dname.len - + ((dialog->rem_dname.len > 0) ? 1 : 0) + dialog->rem_uri.len - + CRLF_LEN - + (((dialog->rem_uri.s[dialog->rem_uri.len - 1] != '>')) ? 2 : 0); + t->to_hdr.len = TO_LEN + dialog->rem_dname.len + + ((dialog->rem_dname.len > 0) ? 1 : 0) + + dialog->rem_uri.len + ((bracket) ? 2 : 0) + CRLF_LEN; memapp(w, TO, TO_LEN); if(dialog->rem_dname.len > 0) { @@ -1589,11 +1587,9 @@ static inline char *print_from( char *w, dlg_t *dialog, struct cell *t, int bracket) { t->from_hdr.s = w; - t->from_hdr.len = - FROM_LEN + dialog->loc_dname.len - + ((dialog->loc_dname.len > 0) ? 1 : 0) + dialog->loc_uri.len - + CRLF_LEN - + ((dialog->loc_uri.s[dialog->loc_uri.len - 1] != '>') ? 2 : 0); + t->from_hdr.len = FROM_LEN + dialog->loc_dname.len + + ((dialog->loc_dname.len > 0) ? 1 : 0) + + dialog->loc_uri.len + ((bracket) ? 2 : 0) + CRLF_LEN; memapp(w, FROM, FROM_LEN); if(dialog->loc_dname.len > 0) {

1 0

[kamailio/kamailio] Kamailio crashes after introducing the change for TCP reads (checks for MSRP first line). (Issue #4642)
by Donat Zenichev 16 Mar '26

16 Mar '26

zenichev created an issue (kamailio/kamailio#4642) ### Description Crash of kamailio (5.7.5) after introducing cefd6f97659cb7572ecb32279e1f57d3b68e0f4c for TCP reads (checks for MSRP first line). I've added this important security related fix to all versions of Kamailio that we maintain, including those long terms supported, as well as those older like 5.7.5. So far the crash happened only in 5.7.5 Keep you posted about other versions (especially those supported). ### Troubleshooting Scope: src/core/tcp_read.c `tcp_init_children()` `tcp_read_headers()` --- `enable_tls=yes` From what we can see it is a simple origination of new call with INVITE request over TLS. Shortly before the crash, we see these log lines: ``` Mar 12 15:41:16.873907 sp1 lb[416237]: CRITICAL: <core> [core/pass_fd.c:85]: recv_all(): 1st recv on 50 failed: Connection reset by peer Mar 12 15:41:16.873924 sp1 lb[416237]: CRITICAL: <core> [core/tcp_main.c:3738]: handle_tcp_child(): read from tcp child 6 (pid 416233, no 31) Connection reset by peer [104] Mar 12 15:41:16.873930 sp1 lb[416237]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 47 Mar 12 15:41:16.874074 sp1 lb[416200]: ALERT: <core> [main.c:792]: handle_sigs(): child process 416233 exited by a signal 11 Mar 12 15:41:16.874087 sp1 lb[416200]: ALERT: <core> [main.c:796]: handle_sigs(): core was generated Mar 12 15:41:16.888319 sp1 lb[416200]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: freeing already freed pointer (0x7f78c1b0ad70), called from tls: tls_init.c: ser_free(399), first free tls: tls_init.c: ser_free(399) - ignoring ``` #### Reproduction Enable TLS with: `enable_tls=yes` Originate a normal call A to B, with the INVITE coming to the TLS socket. Kamailio sends the request further to the registrar via UDP. The registrar server makes the authorization with 407. Kamailio attempts to send 407 to the remote side via TLS socket. (the onreply_route is used for processing of 407). What exactly has triggered this misbehavior (crash) is not known. From what I can see, the actions in TLS were so far: - TLS connection is in this init state (see logs) - TLS connection is reset by remote peer - while being in `tls_init` processing we try to do the double free #### Debugging Data BT trace with excluded sensible data: ``` #0 mem_ctrl (b=0x7f78c198cea0, cmd=3, num=0, ptr=0x7ffce623f970) at ../crypto/bio/bss_mem.c:257 257 ../crypto/bio/bss_mem.c: No such file or directory. (gdb) bt full #0 mem_ctrl (b=0x7f78c198cea0, cmd=3, num=0, ptr=0x7ffce623f970) at ../crypto/bio/bss_mem.c:257 ret = 1 pptr = <optimized out> bbm = <optimized out> bm = 0x63696666 bo = 0x6172742073682073 off = <optimized out> remain = <optimized out> #1 0x00007f78c5308e1d in BIO_ctrl (b=0x7f78c198cea0, cmd=cmd@entry=3, larg=larg@entry=0, parg=parg@entry=0x7ffce623f970) at ../crypto/bio/bio_lib.c:580 ret = <optimized out> __func__ = "BIO_ctrl" #2 0x00007f78c56b104e in ssl3_digest_cached_records (s=s@entry=0x7f78c197c3a8, keep=keep@entry=0) at ../ssl/s3_enc.c:378 md = <optimized out> hdatalen = <optimized out> hdata = 0x7ffce623fa00 __func__ = "ssl3_digest_cached_records" #3 0x00007f78c56fec9b in tls_construct_server_hello (s=0x7f78c197c3a8, pkt=0x7ffce623fa00) at ../ssl/statem/statem_srvr.c:2401 compm = 0 sl = <optimized out> len = 2 version = <optimized out> session_id = <optimized out> usetls13 = <optimized out> __func__ = "tls_construct_server_hello" #4 0x00007f78c56f08ff in write_state_machine (s=0x7f78c197c3a8) at ../ssl/statem/statem.c:855 tmpret = <optimized out> post_work = 0x7f78c5701af0 <ossl_statem_server_post_work> mt = 2 pkt = {buf = 0x7f78c1b0adf0, staticbuf = 0x0, curr = 122, written = 122, maxsize = 18446744073709551615, subs = 0x7f78c1990dd8, endfirst = 0} ret = <optimized out> pre_work = 0x7f78c57018d0 <ossl_statem_server_pre_work> get_construct_message_f = 0x7f78c5701ed0 <ossl_statem_server_construct_message> confunc = 0x7f78c56fea10 <tls_construct_server_hello> st = 0x7f78c197c3f0 transition = 0x7f78c5701480 <ossl_statem_server_write_transition> cb = 0x7f78c5747550 <sr_ssl_ctx_info_callback> st = <optimized out> ret = <optimized out> transition = <optimized out> pre_work = <optimized out> post_work = <optimized out> get_construct_message_f = <optimized out> cb = <optimized out> confunc = <optimized out> mt = <optimized out> pkt = <optimized out> __func__ = "write_state_machine" tmpret = <optimized out> #5 state_machine (s=0x7f78c197c3a8, server=1) at ../ssl/statem/statem.c:451 buf = 0x0 cb = 0x7f78c5747550 <sr_ssl_ctx_info_callback> st = 0x7f78c197c3f0 ret = -1 ssret = <optimized out> __func__ = "state_machine" #6 0x00007f78c5774dd6 in tls_accept (c=c@entry=0x7f78c1a32fb0, error=error@entry=0x7ffce623fc08) at ./src/modules/tls/tls_server.c:457 --Type <RET> for more, q to quit, c to continue without paging--c ret = <optimized out> ssl = 0x7f78c197c3a8 cert = <optimized out> tls_c = 0x7f78c1b2aed0 tls_log = <optimized out> __func__ = "tls_accept" #7 0x00007f78c5780eb0 in tls_h_read_f (c=c@entry=0x7f78c1a32fb0, flags=flags@entry=0x7ffce6260030) at ./src/modules/tls/tls_server.c:1153 r = <optimized out> bytes_free = 65535 bytes_read = <optimized out> read_size = <optimized out> ssl_error = 0 ssl_read = 0 ssl = 0x7f78c197c3a8 rd_buf = "\026\003\001\002\000\001\000\001\374\003\003K^\006\353Kyp\277wb\202UJ3\372/\276\230\017\243\334\317\333;\302b\230\254\232~y\325 \342\357?\350&\3266\247\217\201\212\3026\367\334\b\b\323<\311N\257|\311\035\207\316L\327\300[F\000>\023\002\023\003\023\001\300,\3000\000\237̨̩̪\300+\300/\000\236\300$\300(\000k\300#\300'\000g\300\n\300\024\0009\300\t\300\023\0003\000\235\000\234\000=\000<\0005\000/\000\377\001\000\001u\000\000\000\031\000\027\000\000\024sip01-acit.techit.be\000\v\000\004\003\000\001\002\000\n\000\026\000\024\000\035\000\027\000\036\000\031\000\030\001\000\001\001\001\002"... wr_buf = "\027\003\003\001\032\204\240b)*L\252\246b\2753\v\002\345}\363s֬M\f\372\203\220\261\203\246^3\300}\273O\331\t|\223\017\323\332Y\025\035\245\232\315a\363\035&\3274\227\025\366n\331{\372d\264OY\262v\0013\277k\300\207ki\020\201\031\370\"\213xQ\253po\204\3377rK\375~\\\033\307\021\205\264ۘX\265\361\235\256>[\\ꬣ\223Pk$[\371+<<\021\031\351\006\257\372\247\365\024>*S@f\262\341\375\320fr\214l\216Et\025\343\036bPd\312\322w\362d!\210\261v\225\353\366rjV{=%\323(\024A\021\372g\347\375\354\306t\222\245\255*\026\251\351J\262\020\032~\027\2520Fe\206W"... rd = {buf = 0x7ffce623fcd0 "\026\003\001\002", pos = 517, used = 517, size = 65536} wr = { buf = 0x7ffce624fcd0 "\027\003\003\001\032\204\240b)*L\252\246b\2753\v\002\345}\363s֬M\f\372\203\220\261\203\246^3\300}\273O\331\t|\223\017\323\332Y\025\035\245\232\315a\363\035&\3274\227\025\366n\331{\372d\264OY\262v\0013\277k\300\207ki\020\201\031\370\"\213xQ\253po\204\3377rK\375~\\\033\307\021\205\264ۘX\265\361\235\256>[\\ꬣ\223Pk$[\371+<<\021\031\351\006\257\372\247\365\024>*S@f\262\341\375\320fr\214l\216Et\025\343\036bPd\312\322w\362d!\210\261v\225\353\366rjV{=%\323(\024A\021\372g\347\375\354\306t\222\245\255*\026\251\351J\262\020\032~\027\2520"..., pos = 0, used = 0, size = 65536} tls_c = 0x7f78c1b2aed0 enc_rd_buf = <optimized out> n = <optimized out> flush_flags = 0 err_src = <optimized out> ip_buf = '\000' <repeats 63 times> x = <optimized out> tls_dbg = <optimized out> __func__ = "tls_h_read_f" redo_read = <optimized out> __llevel = <optimized out> __kld = <optimized out> __llevel = <optimized out> __kld = <optimized out> #8 0x0000555ced7b05a1 in tcp_read_headers (c=c@entry=0x7f78c1a32fb0, read_flags=read_flags@entry=0x7ffce6260030) at core/tcp_read.c:445 bytes = <optimized out> remaining = <optimized out> p = <optimized out> r = 0x7f78c1a330d8 mc = <optimized out> body_len = <optimized out> tvnow = {tv_sec = 8295706741926415945, tv_usec = 93857609625105} tvdiff = <optimized out> mfline = <optimized out> mtransid = <optimized out> __func__ = "tcp_read_headers" #9 0x0000555ced7b3214 in tcp_read_req (con=0x7f78c1a32fb0, bytes_read=bytes_read@entry=0x7ffce626002c, read_flags=read_flags@entry=0x7ffce6260030) at core/tcp_read.c:1528 bytes = <optimized out> total_bytes = 0 resp = 1 size = <optimized out> req = 0x7f78c1a330d8 dst = {send_sock = 0x7ffce625ff40, to = {s = {sa_family = 1, sa_data = "\000\000\000\000\000\000P\377%\346\374\177\000"}, sin = {sin_family = 1, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "P\377%\346\374\177\000"}, sin6 = {sin6_family = 1, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = "P\377%\346\374\177\000\000\030\000\000\000\000\000\000", __u6_addr16 = {65360, 58917, 32764, 0, 24, 0, 0, 0}, __u6_addr32 = {3861249872, 32764, 24, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 1, __ss_padding = "\000\000\000\000\000\000P\377%\346\374\177\000\000\030", '\000' <repeats 15 times>, "\3607\245\301x\177\000\000\004P\216\355\\U\000\000\001\000\000\000\000\000\000\0003\000\000\000\000\000\000\000&A\205\001\000\000\000\000`]\246\355\\U\000\000\003t{\355\\U\000\000\004P\216\355\\U\000\000\000ؒ\355\\U\000\0008\000&\346\374\177\000\000\b\000\000\000\000\000\000", __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 11 '\v', proto_pad0 = 0 '\000', proto_pad1 = 0} c = <optimized out> ret = <optimized out> again = <optimized out> __func__ = "tcp_read_req" #10 0x0000555ced7b8280 in handle_io (fm=fm@entry=0x7f78c5b06e30, events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1852 ret = 8 n = 8 read_flags = RD_CONN_SHORT_READ con = 0x7f78c1a32fb0 s = 11 resp = <optimized out> t = <optimized out> ee = 0x0 __func__ = "handle_io" error = <optimized out> #11 0x0000555ced7bde1b in io_wait_loop_epoll (repeat=<optimized out>, t=<optimized out>, h=<optimized out>) at core/io_wait.h:1073 n = 1 r = 0 fm = 0x7f78c5b06e30 revents = 1 __func__ = "io_wait_loop_epoll" #12 0x0000555ced7be677 in tcp_receive_loop (unix_sock=<optimized out>) at core/tcp_read.c:2052 __func__ = "tcp_receive_loop" #13 0x0000555ced7a722c in tcp_init_children (woneinit=woneinit@entry=0x7ffce626055c) at core/tcp_main.c:5377 r = 6 i = <optimized out> reader_fd_1 = 51 pid = <optimized out> si_desc = "tcp receiver (generic)\000\000\000\000\000\000\000\000\000\000\017\000\000\000\000\000\000\000\355Su\355\\U\000\000\004P\216\355\\U\000\0000\352\222\355\\U\000\000\360\236\205\305x\177\000\000\f", '\000' <repeats 15 times>, "\tP\216\355\\U\000\000Ȑ\216\355\\U\000\000X\005\000\000\000\000\000\000\004P\216\355\\U\000\000o>\200\355\\U\000" si = <optimized out> __func__ = "tcp_init_children" error = <optimized out> #14 0x0000555ced5c87ae in main_loop () at ./src/main.c:1937 i = <optimized out> pid = <optimized out> si = <optimized out> si_desc = "udp receiver child=7 sock=127.0.0.1:5060\00060\000\\U\000\000:\254x\305x\177\000\000\022\000\000\000\377\377\377\377DyH\000\000\000\000\000\214\025\205\306x\177\000\000\001\000\000\000\000\000\000\000\t\000\000\000\000\000\000\000Thu Mar \000\245\271\037n8\335\026:20 2026\002\000\000\000\000\000\000" nrprocs = <optimized out> woneinit = 1 __func__ = "main_loop" error = <optimized out> #15 0x0000555ced5bcb39 in main (argc=<optimized out>, argv=<optimized out>) at ./src/main.c:3213 cfg_stream = <optimized out> c = <optimized out> r = <optimized out> tmp = 0x7ffce6260e4d "" tmp_len = 0 port = 0 proto = -961943936 ahost = 0x0 aport = 0 options = 0x555ced8e7b78 ":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 = 2434881523 rfd = <optimized out> debug_save = <optimized out> debug_flag = <optimized out> dont_fork_cnt = <optimized out> n_lst = <optimized out> p = <optimized out> st = {st_dev = 22, st_ino = 879, st_nlink = 2, st_mode = 16872, st_uid = 111, st_gid = 118, __pad0 = 0, st_rdev = 0, st_size = 200, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1771508381, tv_nsec = 869502865}, st_mtim = { tv_sec = 1773323059, tv_nsec = 437452591}, st_ctim = {tv_sec = 1773323059, tv_nsec = 437452591}, __glibc_reserved = {0, 0, 0}} tbuf = "\000\000\000\000\000\000\000\000\200\346\251\306x\177\000\000\r\000\000\000\000\000\000\000\2301\232\306x\177\000\000\220\v&\346\374\177\000\000x,\236\355\\U\000\000 0\255\306x\177\000\000\276\376\252\306x\177\000\000\001", '\000' <repeats 15 times>, "x\b\252\306x\177\000\000\020j\253\306x\177\000\000\000\000\000\000\000\000\000\000\260\n&\346\374\177\000\000\n", '\000' <repeats 15 times>, "\220\v&\346\374\177\000\0003!\253\306x\177\000\000\000\000\000\000\000\000\000\000x,\236\355\\U\000\000\220\v&\346\374\177\000\000\000\000\000\000\000\000\000\000\340B\255\306x\177\000\000\000\000\000\000\000\000\000\000\200F\252\306x\177\000\000"... option_index = 0 long_options = {{name = 0x555ced8e622a "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x555ced8ef7ee "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x555ced8ff0d2 "alias", has_arg = 1, flag = 0x0, val = 1024}, { name = 0x555ced8e622f "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x555ced8e6235 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x555ced8e623e "substdefs", has_arg = 1, flag = 0x0, val = 1027}, { name = 0x555ced8e6248 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x555ced8e6252 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x555ced8e625d "modparam", has_arg = 1, flag = 0x0, val = 1030}, { name = 0x555ced8e6266 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x555ced8ef90b "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x555ced8e6271 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, { name = 0x555ced8e627b "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x555ced8e6282 "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ ``` #### Log Messages Was posted already above, but still adding also to this section: ``` Mar 12 15:41:16.873907 sp1 lb[416237]: CRITICAL: <core> [core/pass_fd.c:85]: recv_all(): 1st recv on 50 failed: Connection reset by peer Mar 12 15:41:16.873924 sp1 lb[416237]: CRITICAL: <core> [core/tcp_main.c:3738]: handle_tcp_child(): read from tcp child 6 (pid 416233, no 31) Connection reset by peer [104] Mar 12 15:41:16.873930 sp1 lb[416237]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 47 Mar 12 15:41:16.874074 sp1 lb[416200]: ALERT: <core> [main.c:792]: handle_sigs(): child process 416233 exited by a signal 11 Mar 12 15:41:16.874087 sp1 lb[416200]: ALERT: <core> [main.c:796]: handle_sigs(): core was generated Mar 12 15:41:16.888319 sp1 lb[416200]: CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: freeing already freed pointer (0x7f78c1b0ad70), called from tls: tls_init.c: ser_free(399), first free tls: tls_init.c: ser_free(399) - ignoring ``` ### Possible Solutions No workaround found so far. ### Additional Information Kamailio 5.7.5 OS: Debian Bookworm -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4642 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4642(a)github.com>

3 9

git:6.1:84de9567: cmake: don't add executable perms to kamctl/kamctl.* files
by Victor Seva 16 Mar '26

16 Mar '26

Module: kamailio Branch: 6.1 Commit: 84de956799df6ee4f4c7bb46249f1477f334111e URL: https://github.com/kamailio/kamailio/commit/84de956799df6ee4f4c7bb46249f147… Author: Victor Seva <vseva(a)sipwork.pro> Committer: Victor Seva <vseva(a)sipwork.pro> Date: 2026-03-16T09:00:56+01:00 cmake: don't add executable perms to kamctl/kamctl.* files > W: kamailio: executable-not-elf-or-script [usr/lib/x86_64-linux-gnu/kamailio/kamctl/kamctl.base] (cherry picked from commit bbf67a6d94427da38d32b361e15175bce3d2195f) --- Modified: cmake/db_files.cmake --- Diff: https://github.com/kamailio/kamailio/commit/84de956799df6ee4f4c7bb46249f147… Patch: https://github.com/kamailio/kamailio/commit/84de956799df6ee4f4c7bb46249f147… --- diff --git a/cmake/db_files.cmake b/cmake/db_files.cmake index 89ea86129ef..cb8c04057d0 100644 --- a/cmake/db_files.cmake +++ b/cmake/db_files.cmake @@ -33,7 +33,7 @@ function(add_db_files group_name file kamctl) set_property(GLOBAL APPEND PROPERTY KAMDBCTL_DEPENDENCIES "kamdbctl_${file}") endif() install( - PROGRAMS ${CMAKE_BINARY_DIR}/utils/kamctl/${file} + FILES ${CMAKE_BINARY_DIR}/utils/kamctl/${file} DESTINATION ${CMAKE_INSTALL_LIBDIR}/${MAIN_NAME}/kamctl COMPONENT ${group_name} )

1 0

git:master:bbf67a6d: cmake: don't add executable perms to kamctl/kamctl.* files
by Victor Seva 16 Mar '26

16 Mar '26

Module: kamailio Branch: master Commit: bbf67a6d94427da38d32b361e15175bce3d2195f URL: https://github.com/kamailio/kamailio/commit/bbf67a6d94427da38d32b361e15175b… Author: Victor Seva <vseva(a)sipwork.pro> Committer: Victor Seva <vseva(a)sipwork.pro> Date: 2026-03-16T08:54:51+01:00 cmake: don't add executable perms to kamctl/kamctl.* files > W: kamailio: executable-not-elf-or-script [usr/lib/x86_64-linux-gnu/kamailio/kamctl/kamctl.base] --- Modified: cmake/db_files.cmake --- Diff: https://github.com/kamailio/kamailio/commit/bbf67a6d94427da38d32b361e15175b… Patch: https://github.com/kamailio/kamailio/commit/bbf67a6d94427da38d32b361e15175b… --- diff --git a/cmake/db_files.cmake b/cmake/db_files.cmake index 89ea86129ef..cb8c04057d0 100644 --- a/cmake/db_files.cmake +++ b/cmake/db_files.cmake @@ -33,7 +33,7 @@ function(add_db_files group_name file kamctl) set_property(GLOBAL APPEND PROPERTY KAMDBCTL_DEPENDENCIES "kamdbctl_${file}") endif() install( - PROGRAMS ${CMAKE_BINARY_DIR}/utils/kamctl/${file} + FILES ${CMAKE_BINARY_DIR}/utils/kamctl/${file} DESTINATION ${CMAKE_INSTALL_LIBDIR}/${MAIN_NAME}/kamctl COMPONENT ${group_name} )

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev