### 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
Hi
When I register to my IMS core (Kamailio version 5.2), ims_registrar_scscf modul sends notification with XML body showing all contacts with expires "0".
I noticed that , in ims_registrar_scscf module, the notify_subscribers function is as shown below:
```
int notify_subscribers(impurecord_t* impurecord, str *explit_dereg_contact, int num_explit_dereg_contact) {
event_reg(0, impurecord, IMS_REGISTRAR_CONTACT_UNREGISTERED, 0, 0, explit_dereg_contact, num_explit_dereg_contact);
return 0;
}
```
IMS_REGISTRAR_CONTACT_UNREGISTERED parameter is hardcoded.
I noticed that in upper version of Kamailio this changed like that:
```
int notify_subscribers(impurecord_t* impurecord, ucontact_t* contact, str *explit_dereg_contact, int num_explit_dereg_contact, int event_type) {
event_reg(0, impurecord, contact, event_type, 0, 0, 0, explit_dereg_contact, num_explit_dereg_contact);
return 0;
}
```
Also noticed that in upper version of Kamailio notify_subscribers is only called on de-registration. But in version 5.2 it is called on registration and re-registration also. (This leads strange cases)
Could you please advise on this issue?
Best regards
Erhan
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### 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.
-->
```
(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`
```
[stack@ims-test2 ~]$ /usr/local/sbin/kamailio -v
version: kamailio 5.2.0 (x86_64/linux) 40c16b
```
* **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 `uname -a`)
-->
```
[stack@ims-test2 ~]$ uname -a
Linux ims-test2.novalocal 3.10.0-1062.1.1.el7.x86_64 #1 SMP Fri Sep 13 22:55:44 UTC 2019 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/2692