From the build log
```
CC (gcc) [M kazoo.so] kazoo.o
CC (gcc) [M kazoo.so] kz_amqp.o
kz_amqp.c: In function 'kz_amqp_connection_open_ssl':
kz_amqp.c:857:17: warning: 'amqp_set_initialize_ssl_library' is deprecated [-Wdeprecated-declarations]
857 | amqp_set_initialize_ssl_library(1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from kz_amqp.c:37:
/usr/include/rabbitmq-c/ssl_socket.h:233:16: note: declared here
233 | void AMQP_CALL amqp_set_initialize_ssl_library(amqp_boolean_t do_initialize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC (gcc) [M kazoo.so] kz_fixup.o
CC (gcc) [M kazoo.so] kz_hash.o
```
Functions description in the header file
https://github.com/alanxz/rabbitmq-c/blob/v0.13.0/include/rabbitmq-c/ssl_so…
```
/**
* Sets whether rabbitmq-c will initialize OpenSSL.
*
* \deprecated Since v0.13.0 this is a no-op. OpenSSL automatically manages
* library initialization and uninitialization.
*
* OpenSSL requires a one-time initialization across a whole program, this sets
* whether or not rabbitmq-c will initialize the SSL library when the first call
* to amqp_ssl_socket_new() is made. You should call this function with
* do_init = 0 if the underlying SSL library is initialized somewhere else
* the program.
*
* Failing to initialize or double initialization of the SSL library will
* result in undefined behavior
*
* By default rabbitmq-c will initialize the underlying SSL library.
*
* NOTE: calling this function after the first socket has been opened with
* amqp_open_socket() will not have any effect.
*
* \param [in] do_initialize If 0 rabbitmq-c will not initialize the SSL
* library, otherwise rabbitmq-c will initialize the
* SSL library
*
* \since v0.4.0
*/
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3466
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3466(a)github.com>
warning on alpine dist
```
In file included from kz_amqp.c:32:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
In file included from kz_amqp.c:33:
/usr/include/amqp_framing.h:8:2: warning: #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead. [-Wcpp]
8 | #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead.
| ^~~~~~~
In file included from kz_amqp.c:34:
/usr/include/amqp_tcp_socket.h:7:2: warning: #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead." [-Wcpp]
7 | #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead."
| ^~~~~~~
In file included from kz_amqp.c:35:
/usr/include/amqp_ssl_socket.h:9:2: warning: #warning "amqp_ssl_socket.h is deprecated, use rabbitmq-c/ssl_socket.h instead. [-Wcpp]
9 | #warning "amqp_ssl_socket.h is deprecated, use rabbitmq-c/ssl_socket.h instead.
| ^~~~~~~
In file included from kz_amqp.h:35,
from kazoo.c:36:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
kz_amqp.c: In function 'kz_amqp_connection_open_ssl':
kz_amqp.c:815:13: warning: 'amqp_set_initialize_ssl_library' is deprecated [-Wdeprecated-declarations]
815 | amqp_set_initialize_ssl_library(1);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/amqp_ssl_socket.h:11:
/usr/include/rabbitmq-c/ssl_socket.h:233:16: note: declared here
233 | void AMQP_CALL amqp_set_initialize_ssl_library(amqp_boolean_t do_initialize);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CC (gcc) [M kazoo.so] kz_fixup.o
CC (gcc) [M kazoo.so] kz_hash.o
In file included from kz_amqp.h:35,
from kz_hash.h:33,
from kz_hash.c:29:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
CC (gcc) [M kazoo.so] kz_json.o
CC (gcc) [M kazoo.so] kz_pua.o
kz_amqp.c: In function 'kz_amqp_send_ex':
kz_amqp.c:2327:12: warning: 'num_headers' may be used uninitialized [-Wmaybe-uninitialized]
2327 | if (num_headers > 0) {
| ^
kz_amqp.c:2281:9: note: 'num_headers' was declared here
2281 | int num_headers = 0;
| ^~~~~~~~~~~
CC (gcc) [M kazoo.so] kz_trans.o
In file included from kz_amqp.h:35,
from kz_trans.c:54:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
make[3]: Entering directory '/usr/src/kamailio/pkg/kamailio/alpine/src/kamailio-95d33167cff13190b51c04b5347df6d419cf2630/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-95d33167cff13190b51c04b5347df6d419cf2630/src/lib/srdb1'
LD (gcc) [M kazoo.so] kazoo.so
make[2]: --libs: No such file or directory
make[2]: --libs: No such file or directory
CC (gcc) [M rabbitmq.so] rabbitmq.o
CC (gcc) [M rabbitmq.so] utils.o
In file included from utils.c:47:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
In file included from utils.c:48:
/usr/include/amqp_framing.h:8:2: warning: #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead. [-Wcpp]
8 | #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead.
| ^~~~~~~
In file included from rabbitmq.c:55:
/usr/include/amqp_tcp_socket.h:7:2: warning: #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead." [-Wcpp]
7 | #warning "amqp_tcp_socket.h is deprecated, use rabbitmq-c/tcp_socket.h instead."
| ^~~~~~~
In file included from rabbitmq.c:56:
/usr/include/amqp.h:7:2: warning: #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead." [-Wcpp]
7 | #warning "amqp.h is deprecated, use rabbitmq-c/amqp.h instead."
| ^~~~~~~
In file included from rabbitmq.c:57:
/usr/include/amqp_framing.h:8:2: warning: #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead. [-Wcpp]
8 | #warning "amqp_framing.h is deprecated, use rabbitmq-c/framing.h instead.
| ^~~~~~~
LD (gcc) [M rabbitmq.so] rabbitmq.so
CC (gcc) [M sctp.so] sctp_mod.o
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3464
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3464(a)github.com>
hello ,
I 'm trying to change value "xhttp_prom_timeout" to specific value , for instance 1 minute , to do i set command : modparam("xhttp_prom", "xhttp_prom_timeout", 1) , but it seems metrics is not deleted after 1 minute of not using this metric , only metric is deleted after 10 hours , even i set xhttp_prom_timeoutto 1
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3439
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3439(a)github.com>
### Description
_**Sipwise** hat on_
We noticed that pkg memory was getting exhausted and we found out that pv_cache_add() was the origin of the allocations.
We are using ``$xavp(user_<UUID>)`` variables that, for sure, are kind of dynamic.
There is a pv_cache_drop() that tries to remove ``$sht()`` occurrences when the cache is about to be filled but in our case that's not helping.
#### Log Messages
```
WARNING: ROUTE_SET_CALLEE_DIALOG_TOTAL <core> [core/pvapi.c:340]: pv_cache_add(): pv cache limit is going to be exceeded - pkg memory may get filled with pv declarations
WARNING: dialog:failed <core> [core/pvapi.c:340]: pv_cache_add(): pv cache limit is going to be exceeded - pkg memory may get filled with pv declarations
```
### Possible Solutions
Possible solutions that came on the top of my head:
- add a datetime member to struct _pv_cache so we can keep the last time it was accessed and search for the oldest and remove them in pv_cache_drop()
- add pv module parameter to define a magic prefix, for instance '__' that will mark those vars as "temporal" should remove it from cache when needed.
- add pv module parameter to control what types of variables will be added to cache
Any thoughts about this?
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3440
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3440(a)github.com>
### Description
We've been experiencing random Kamailio crashes related to invalid memory access attempts at `0xffff` in `w_save` call, `ims_registrar_scscf_mod.c`:
```
Core was generated by `kamailio -w /home -DD -E -e -f /etc/kamailio/kamailio_scscf.cfg'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f5be796c452 in w_save (_m=0x7f5beafa5188, _route=0x7f5beaeab988 " \b\361\352[\177", _d=0x7f5be3bf8200 "", mode=0x7f5beafa5188 "4", _cflags=0xffff <error: Cannot access memory at address 0xffff>)
at ims_registrar_scscf_mod.c:628
```
We are running the latest Kamailio 5.6.4 using the official Docker image.
### Analysis
We were able to analyze corresponding core dump using `gdb` and determine the cause of those random crashes. It turns out that it is related to calling the `save` function of IMS Registrar SCSCF module with 2 arguments.
Example configuration:
```
save("REG_SAR_REPLY", "location");
```
According to documentation, this call is valid, as `mode` and `flags` parameters are optional:
https://kamailio.org/docs/modules/5.6.x/modules/ims_registrar_scscf.html#id…
The `save` function is exported in `ims_registrar_scscf_mod.c` as follows:
```
/*! \brief
* Exported functions
*/
static cmd_export_t cmds[] = {
{"save", (cmd_function) w_save, 2, assign_save_fixup3_async, 0, REQUEST_ROUTE | ONREPLY_ROUTE},
{"save", (cmd_function) w_save, 3, assign_save_fixup3_async, 0, REQUEST_ROUTE | ONREPLY_ROUTE},
{"save", (cmd_function) w_save, 4, save_fixup3, free_uint_fixup, REQUEST_ROUTE | ONREPLY_ROUTE},
...
}
```
And implemented as:
```
/*! \brief
* Wrapper to save(location)
*/
static int w_save(struct sip_msg* _m, char* _route, char* _d, char* mode, char* _cflags) {
if(_cflags){
return save(_m, _d, _route, ((int)(*_cflags)));
}
return save(_m, _d, _route, 0);
}
```
Using the 2-argument `save` variant in configuration effectively causes the `w_save` to be called from `src/core/action.c :: do_action` via a 3-argument function-pointer cast:
```
case MODULE2_T:
MODF_CALL(cmd_function, h, msg, a->val,
(char*)a->val[2].u.data,
(char*)a->val[3].u.data
);
break;
```
Unfortunately, this cast is inherently unsafe - it leaves the `mode` and `_cflags` undetermined. They are probably effectively bound to some memory area beyond the parameter values of the stack frame corresponding to the function call.
Our guess is that incidentally `_cflags == 0x0000` for most of those calls, due to how the stack is structured. But sometimes `_cflags == 0xFFFF` which satisfies the condition in `w_save`, causes `(int)(*_cflags)` dereference attempt and leads to the segmentation fault we've encountered.
### Workaround
Based on source code analysis, we have determined that always using `save` with a full set of arguments (including optional ones) will result in `w_save` being called via a 5-argument function pointer, which matches its signature and avoids the issue.
Example configuration with workaround applied:
```
save("REG_SAR_REPLY", "location", "0", "0");
```
After introducing this workaround on target environment we are no longer experiencing the problem.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3412
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3412(a)github.com>
We had a Kamailio 5.5.4 server crash. There were lots of the following errors repeated over and over in the Kamailio log:
Mar 10 14:59:14 px1 /usr/sbin/kamailio[1375]: WARNING: <core> [core/tcp_read.c:1840]: handle_io(): F_TCPCONN connection marked as bad: 0x7f48e97ecdc8 id 0 fd -1 refcnt 0 ([]:0 -> []:0)
Mar 10 14:59:14 px1 /usr/sbin/kamailio[1375]: CRITICAL: <core> [core/io_wait.h:596]: io_watch_del(): invalid fd -1, not in [0, 2)
And in the syslog it said:
Mar 10 14:59:14 px1 kernel: [731786.728781] kamailio[1363]: segfault at 10 ip 00007f48e6dde42d sp 00007ffc2d23ef00 error 4 in tls.so[7f48e6d9c000+47000]
Mar 10 14:59:14 px1 kernel: [731786.728814] Code: 98 01 5c 24 28 41 29 dd 49 01 84 24 40 01 00 00 c7 44 24 6c 00 00 00 00 85 c9 0f 85 be 08 00 00 49 8b 94 24 90 01 00 00 31
f6 <48> 8b 7a 10 31 d2 e8 38 10 fc ff 85 c0 0f 8e 90 0d 00 00 45 31 db
Is anyone able to advise whether this is a known issue, and if it's fixed in a more recent version? The only related bug report I found was issue #748 which was closed without resolution. Our Kamailio is installed from the Ubuntu 22.04 repository.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3392
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3392(a)github.com>
Hi,
I think there is an issue with writing CDRs on failover scenarios.
I have two servers with Kamailio. Both server running Debian 11 (bulleye) and latest Kamailio 5.6.1 from git.
I'm using DMQ to sync dialogs and htable between these servers, so both servers have the same knowledge of dialog state. Both Kamailio uses nobind option, so I can switch a VIP from one server to the other one. This is managed with keepalived. Switching the VIP from one server the other one works fine an while a call is running I can switch the VIP. I can see that the BYE Message is handled OK after I made a switch. I can see that acc is triggered but what is missing is acc_cdr in this case.
I'm using htable to fill all necessary variables to complete the CDR an I can see that all values are synced correctly.
The acc_cdr is created fine if there is no failover so i think it can't be an configuration issue.
Both server holds the same Kamailio configuration except the IP.
`version: kamailio 5.6.1 (x86_64/linux) bfc5c2-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_BLOCKLIST, 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: bfc5c2 -dirty
compiled with gcc 10.2.1`
`root@voip-lab-proxy01:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye`
`root@voip-lab-proxy01:~# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
Address sizes: 38 bits physical, 48 bits virtual
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 23
Model name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
Stepping: 10
CPU MHz: 2500.088
BogoMIPS: 5000.17
Virtualization: VT-x
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 128 KiB
L1i cache: 128 KiB
L2 cache: 16 MiB
L3 cache: 16 MiB
NUMA node0 CPU(s): 0-3
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Mitigation; PTE Inversion; VMX EPT disabled
Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown
Vulnerability Meltdown: Mitigation; PTI
Vulnerability Mmio stale data: Unknown: No mitigations
Vulnerability Retbleed: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort: Not affected
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid
tsc_known_freq pni vmx ssse3 cx16 pdcm sse4_1 x2apic tsc_deadline_timer xsave hypervisor lahf_lm cpuid_fault pti tpr_shadow vnmi flexpriority vpid tsc_adjust arat arch_capabilit
ies`
If you need more information, please let me know. As I'm running this on a test system I can reproduce the issue at any time.
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3254
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3254(a)github.com>