#### Description
This PR introduces `event_routes` that will trigger when `dmq peers` go up and down during the time.
Really useful to detect problems between `peers` and allows addition of prometheus metrics for example, to add automatic visibility.
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [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
- [ ] 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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [x] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Tests
Tested locally simulating crashes and startups to evaluate the trigger of routes.
Couldn't found any problems or strange cases, on ping intervals the status validation, gives the correct output.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4661
-- Commit Summary --
* dmqueue: add peer up and down event routes
-- File Changes --
M src/modules/dmq/dmq.c (68)
M src/modules/dmq/dmq.h (3)
M src/modules/dmq/dmqnode.c (30)
M src/modules/dmq/dmqnode.h (2)
M src/modules/dmq/doc/dmq_admin.xml (79)
M src/modules/dmq/notification_peer.c (22)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4661.patchhttps://github.com/kama…
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4661
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4661(a)github.com>
fulhade created an issue (kamailio/kamailio#4431)
Testing 6.0.3 noticed that log is filled with INFO log messages from title (every 5s). No errors in logs, usual stuff except info on tcpcon
```
Oct 12 00:40:24 kamailio[4350]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 38
Oct 12 22:42:26 kamailio[4355]: INFO: <core> [core/tcp_main.c:3124]: tcpconn_1st_send(): quick connect for 0x7f78f8c79b10 sock 32
...
Oct 13 07:42:12 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:17 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:22 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:27 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:32 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
Oct 13 07:42:37 kamailio[4355]: INFO: http_async_client [http_multi.c:88]: event_cb(): Cell for handler 0x7f78f8c79b10 not found in table
```
Using docker image built on trixie: https://pastebin.com/0wZ0X9wb
Not sure how to reproduce, it just appear on testing machine after couple of days.
Unfortunately we used 5.6.3 before this, so not sure when did it break for us. http_async_client usage:
```
$http_req(hdr) = "Content-Type: application/json";
$http_req(hdr) = "Expect: ";
$http_req(body) = $dlg_var(http_body);
http_async_query("${URL}/RoutingService/route", "ROUTING_RESPONSE");
```
Memory looks fine, but one of four CPU core spike to 96%.
<img width="1119" height="955" alt="Image" src="https://github.com/user-attachments/assets/ffff8680-84ad-4866-9892-a6e6eefd…" />
core.tcp_info, mod.stats all shm, mod.stats all pkg https://pastebin.com/QLZ8mZdD
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4431
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4431(a)github.com>
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.patchhttps://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>
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>
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [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)
- [ ] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
fix wrong connections reuse in tls_connection_match_domain=yes mode and add test for it
* change related places for tls and tls_wolfssl modules
* fix protocol checking in _tcpconn_find
* add test/unit/62.sh
test/unit/62.sh execution time:
```
test/unit$ time make run UNIT=62.sh
Run test 62: checks tls_connection_match_domain=yes creates new connection to the same dst ip:port for another tls domain
Test unit file 62.sh: ok
real 0m1.191s
user 0m0.048s
sys 0m0.019s
```
was wrongly reusing the same TLS connection even between different TLS domains because:
* invalid proto check in _tcpconn_find was skipping tls hook match_domain when it called with proto:0
* passing connection ptr to the get_tls_domain_str in tls_h_match_domain_f was causing tls_get_connect_server_name,tls_get_connect_server_id to check connection against itself instead of XAVPs lookup for the new connection context
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4676?email_source=notifications&a…
-- Commit Summary --
* tls: fix tls_h_match_domain_f connection matching
* tls_wolfssl: fix tls_h_match_domain_f connection matching
* core: _tcpconn_find: fix protocol checking for tls_connection_match_domain
* test: add unit/62.sh for tls_connection_match_domain=yes
-- File Changes --
M src/core/tcp_main.c (2)
M src/modules/tls/tls_server.c (4)
M src/modules/tls_wolfssl/tls_server.c (4)
A test/unit/62.cfg (37)
A test/unit/62.sh (131)
A test/unit/62_tls.cfg (11)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4676.patch?email_source=notificat…
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4676
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4676(a)github.com>
itpanda2024 created an issue (kamailio/kamailio#4467)
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
Note that an issue report may be closed automatically after about 2 months
if there is no interest from developers or community users on pursuing it, being
considered expired. In such case, it can be reopened by writing a comment that includes
the token `/notexpired`. About two weeks before considered expired, the issue is
marked with the label `stale`, trying to notify the submitter and everyone else
that might be interested in it. To remove the label `stale`, write a comment that
includes the token `/notstale`. Also, any comment postpone the `expire` timeline,
being considered that there is interest in pursuing the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
We use db_cluster module with configuration below :
loadmodule "db_mysql.so"
modparam("db_mysql", "timeout_interval", 2)
loadmodule "db_cluster.so"
modparam("db_mysql", "timeout_interval", 2)
modparam("db_cluster", "connection","cfig_db1=>mysql://kamailio:kamailiorw@localhost/kamailio")
modparam("db_cluster", "connection","cfig_db2=>mysql://kamailio_user:Kam2025Db@172.20.22.12/kamailio")
modparam("db_cluster", "cluster", "cfig_db=>cfig_db1=9s8r;cfig_db2=9s8r")
modparam("db_cluster", "inactive_interval", 180)
modparam("db_cluster", "max_query_length", 5)
But we stop db1 . Kamailio fail ,not change to connect db2 and kamailio service stoped.
-->
### Troubleshooting
#### Reproduction
<!--
Nov 11 09:43:56 kam-02 kamailio[249517]: 391(249517) INFO: db_cluster [db_cluster_mod.c:192]: dbcl_rpc_list_connections(): read connection [cfig_db2]
Nov 11 09:43:56 kam-02 kamailio[249517]: 391(249517) INFO: db_cluster [db_cluster_mod.c:192]: dbcl_rpc_list_connections(): read connection [cfig_db1]
Nov 11 09:44:12 kam-02 kamailio[249509]: 387(249509) ERROR: db_mysql [km_dbase.c:129]: db_mysql_submit_query_impl(): driver error on query: Can't connect to local server through socket '/var/lib/mysql/mysql.sock' (2) (2002)
Nov 11 09:44:12 kam-02 kamailio[249509]: 387(249509) ERROR: <core> [db_query.c:335]: db_do_delete(): error while submitting query
Nov 11 09:44:12 kam-02 kernel: kamailio[249509]: segfault at 0 ip 00007f02cb456312 sp 00007fff12a9a3f0 error 4 in db_cluster.so[12312,7f02cb446000+2f000] likely on CPU 3 (core 0, socket 6)
Nov 11 09:44:12 kam-02 kernel: Code: 84 89 c7 e8 c0 fd fe ff 48 8b 4d a0 8b 45 c0 48 63 f0 8b 45 c4 48 63 d0 48 89 d0 48 c1 e0 03 48 29 d0 48 01 f0 48 8b 44 c1 18 <4c> 8b 38 48 8b 4d a0 8b 45 c0 48 63 f0 8b 45 c4 48 63 d0 48 89 d0
Nov 11 09:44:12 kam-02 systemd-coredump[249541]: Process 249509 (kamailio) of user 993 terminated abnormally with signal 11/SEGV, processing...
Nov 11 09:44:12 kam-02 systemd[1]: Started systemd-coredump(a)2-249541-0.service - Process Core Dump (PID 249541/UID 0).
Nov 11 09:44:13 kam-02 systemd-coredump[249542]: Process 249509 (kamailio) of user 993 dumped core.#012#012Module libuuid.so.1 from rpm util-linux-2.40.2-10.el10.x86_64#012Module libpcre2-8.so.0 from rpm pcre2-10.44-1.0.1.el10.3.x86_64#012Module libcrypt.so.2 from rpm libxcrypt-4.4.36-10.el10.x86_64#012Module libselinux.so.1 from rpm libselinux-3.8-2.el10_0.x86_64#012Module libbrotlicommon.so.1 from rpm brotli-1.1.0-6.el10.x86_64#012Module libsasl2.so.3 from rpm cyrus-sasl-2.1.28-27.el10.x86_64#012Module libevent-2.1.so.7 from rpm libevent-2.1.12-16.el10.x86_64#012Module libkeyutils.so.1 from rpm keyutils-1.6.3-5.el10.x86_64#012Module libkrb5support.so.0 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64#012Module libcom_err.so.2 from rpm e2fsprogs-1.47.1-3.el10.x86_64#012Module libk5crypto.so.3 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64#012Module libkrb5.so.3 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64#012Module libunistring.so.5 from rpm libunistring-1.1-10.el10.x86_64#012Module libz.so.1 from rpm zlib-ng-2.2.3-1.el10.x86_64#012Module libbrotlidec.so.1 from rpm brotli-1.1.0-6.el10.x86_64#012Module libgssapi_krb5.so.2 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64#012Module libcrypto.so.3 from rpm openssl-3.2.2-16.0.1.el10_0.4.x86_64#012Module libssl.so.3 from rpm openssl-3.2.2-16.0.1.el10_0.4.x86_64#012Module libpsl.so.5 from rpm libpsl-0.21.5-6.el10.x86_64#012Module libssh.so.4 from rpm libssh-0.11.1-4.el10_0.x86_64#012Module libidn2.so.0 from rpm libidn2-2.3.7-3.el10.x86_64#012Module libnghttp2.so.14 from rpm nghttp2-1.64.0-2.el10.x86_64#012Module libcurl.so.4 from rpm curl-8.9.1-5.el10.x86_64#012Module libcap.so.2 from rpm libcap-2.69-7.el10.x86_64#012Module libnss_myhostname.so.2 from rpm systemd-257-9.0.1.el10_0.1.x86_64#012Stack trace of thread 249509:#012#0 0x00007f02cb456312 db_cluster_delete (db_cluster.so + 0x12312)#012#1 0x00007f02cb3b461d tps_db_clean_branches (topos.so + 0x2e61d)#012#2 0x00007f02cb3cae2f tps_storage_clean (topos.so + 0x44e2f)#012#3 0x00000000006dd64f sr_wtimer_exec (/usr/local/sbin/kamailio + 0x2dd64f)#012#4 0x00000000006dc71d fork_sync_timer (/usr/local/sbin/kamailio + 0x2dc71d)#012#5 0x00000000006dd9c3 sr_wtimer_start (/usr/local/sbin/kamailio + 0x2dd9c3)#012#6 0x000000000042eea0 main_loop (/usr/local/sbin/kamailio + 0x2eea0)#012#7 0x000000000043902c main (/usr/local/sbin/kamailio + 0x3902c)#012#8 0x00007f02f04f230e __libc_start_call_main (libc.so.6 + 0x2a30e)#012#9 0x00007f02f04f23c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a3c9)#012#10 0x000000000041dc65 _start (/usr/local/sbin/kamailio + 0x1dc65)#012ELF object binary architecture: AMD x86-64
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
Module libuuid.so.1 from rpm util-linux-2.40.2-10.el10.x86_64
Module libpcre2-8.so.0 from rpm pcre2-10.44-1.0.1.el10.3.x86_64
Module libcrypt.so.2 from rpm libxcrypt-4.4.36-10.el10.x86_64
Module libselinux.so.1 from rpm libselinux-3.8-2.el10_0.x86_64
Module libbrotlicommon.so.1 from rpm brotli-1.1.0-6.el10.x86_64
Module libsasl2.so.3 from rpm cyrus-sasl-2.1.28-27.el10.x86_64
Module libevent-2.1.so.7 from rpm libevent-2.1.12-16.el10.x86_64
Module libkeyutils.so.1 from rpm keyutils-1.6.3-5.el10.x86_64
Module libkrb5support.so.0 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64
Module libcom_err.so.2 from rpm e2fsprogs-1.47.1-3.el10.x86_64
Module libk5crypto.so.3 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64
Module libkrb5.so.3 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64
Module libunistring.so.5 from rpm libunistring-1.1-10.el10.x86_64
Module libz.so.1 from rpm zlib-ng-2.2.3-1.el10.x86_64
Module libbrotlidec.so.1 from rpm brotli-1.1.0-6.el10.x86_64
Module libgssapi_krb5.so.2 from rpm krb5-1.21.3-8.0.1.el10_0.x86_64
Module libcrypto.so.3 from rpm openssl-3.2.2-16.0.1.el10_0.4.x86_64
Module libssl.so.3 from rpm openssl-3.2.2-16.0.1.el10_0.4.x86_64
Module libpsl.so.5 from rpm libpsl-0.21.5-6.el10.x86_64
Module libssh.so.4 from rpm libssh-0.11.1-4.el10_0.x86_64
Module libidn2.so.0 from rpm libidn2-2.3.7-3.el10.x86_64
Module libnghttp2.so.14 from rpm nghttp2-1.64.0-2.el10.x86_64
Module libcurl.so.4 from rpm curl-8.9.1-5.el10.x86_64
Module libcap.so.2 from rpm libcap-2.69-7.el10.x86_64
Module libnss_myhostname.so.2 from rpm systemd-257-9.0.1.el10_0.1.x86_64
Stack trace of thread 250950:
#0 0x00007feac2913312 db_cluster_delete (db_cluster.so + 0x12312)
#1 0x00007feac287161d tps_db_clean_branches (topos.so + 0x2e61d)
#2 0x00007feac2887e2f tps_storage_clean (topos.so + 0x44e2f)
#3 0x00000000006dd64f sr_wtimer_exec (/usr/local/sbin/kamailio + 0x2dd64f)
#4 0x00000000006dc71d fork_sync_timer (/usr/local/sbin/kamailio + 0x2dc71d)
#5 0x00000000006dd9c3 sr_wtimer_start (/usr/local/sbin/kamailio + 0x2dd9c3)
#6 0x000000000042eea0 main_loop (/usr/local/sbin/kamailio + 0x2eea0)
#7 0x000000000043902c main (/usr/local/sbin/kamailio + 0x3902c)
#8 0x00007feae79ac30e __libc_start_call_main (libc.so.6 + 0x2a30e)
#9 0x00007feae79ac3c9 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a3c9)
#10 0x000000000041dc65 _start (/usr/local/sbin/kamailio + 0x1dc65)
ELF object binary architecture: AMD x86-64
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4467
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4467(a)github.com>
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [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
- [ ] 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:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
In this PR we introduce a new mode and two new parameters for accomplishing the same thing for user part also in domain part.
Docs incoming if no significant changes are needed.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/4246
-- Commit Summary --
* topos: Add new contact_mode=3 and 2 new modparam for contact host domains
* topos: Refactor contact_mode handling
* topos: Append port and protocol param
-- File Changes --
M src/modules/topos/topos_mod.c (13)
M src/modules/topos/tps_storage.c (428)
M src/modules/topos/tps_storage.h (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/4246.patchhttps://github.com/kamailio/kamailio/pull/4246.diff
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4246
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4246(a)github.com>
mkl262 created an issue (kamailio/kamailio#4416)
Hello,
Im asking to add the JWT Module to the default list of modules that are being built and uploaded to [deb.kamailio.org](https://deb.kamailio.org/).
Will editing the CMAKE scripts will be enough (in which case I can open a PR for it), or does it require modifying the Jenkins pipelines?
Thanks,
Michael.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4416
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4416(a)github.com>
sergey-safarov created an issue (kamailio/kamailio#4585)
### Description
```
CC (cc) [M ims_dialog.so] dlg_var.o
CC (cc) [M ims_dialog.so] ims_dialog.o
ims_dialog.c: In function 'mod_init':
ims_dialog.c:535:27: error: passing argument 1 of 'register_timer' from incompatible pointer type [-Wincompatible-pointer-types]
535 | if(register_timer(print_all_dlgs, 0, 10) < 0) {
| ^~~~~~~~~~~~~~
| |
| void (*)(void)
In file included from ../../core/pt.h:31,
from ../../core/counters.h:37,
from ../../core/sr_module.h:42,
from ims_dialog.c:7:
../../core/timer.h:189:35: note: expected 'void (*)(unsigned int, void *)' but argument is of type 'void (*)(void)'
189 | int register_timer(timer_function f, void *param, unsigned int interval);
| ~~~~~~~~~~~~~~~^
In file included from ims_dialog.c:27:
dlg_handlers.h:197:6: note: 'print_all_dlgs' declared here
197 | void print_all_dlgs();
| ^~~~~~~~~~~~~~
make[3]: Entering directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-28bd46f1f22ffacf859504768e7284591ccba126/src/lib/srdb1'
make[3]: 'libsrdb1.so.1.0' is up to date.
make[3]: Leaving directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-28bd46f1f22ffacf859504768e7284591ccba126/src/lib/srdb1'
make[2]: *** [../../Makefile.rules:100: ims_dialog.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:509: modules] Error 1
make[1]: Leaving directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-28bd46f1f22ffacf859504768e7284591ccba126/src'
make: *** [Makefile:34: all] Error 2
>>> ERROR: kamailio: build failed
>>> kamailio: Uninstalling dependencies...
```
### Additional Information
* **Operating System**:
```
/ $ cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.23.3
PRETTY_NAME="Alpine Linux v3.23"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4585
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4585(a)github.com>
sznoname created an issue (kamailio/kamailio#4669)
Segmentation Fault on Ctrl-C with No Fork Mode
Environment
- OS: Debian 13.3
- Kamailio Version: 6.1.1 (x86_64/Linux)
Relevant Configuration (/etc/kamailio/kamailio.cfg)
log_stderror=yes
fork=no
auto_aliases=no
tcp_accept_no_cl=yes
loadmodule "jsonrpcs.so"
loadmodule "kex.so"
loadmodule "corex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "rr.so"
loadmodule "pv.so"
loadmodule "maxfwd.so"
loadmodule "siputils.so"
loadmodule "xlog.so"
loadmodule "sanity.so"
loadmodule "ctl.so"
loadmodule "nats.so"
modparam("nats", "nats_url", "nats://127.0.0.1:4222")
modparam("nats", "subject_queue_group", "Kamailio-World:2026")
request_route {
sl_send_reply("403", "Not relaying");
exit;
}
Steps to Reproduce
1. Start Kamailio in foreground mode with the given configuration: kamailio
2. Stop the running process using Ctrl-C
Observed Output and Crash
WARNING: no fork mode and more than one listen address found (will use only the first one)
0(9286) WARNING: <core> [main.c:1460]: main_loop(): using only the first listen address (no fork)
^CSegmentation fault (core dumped)
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/4669
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/4669(a)github.com>