The former respects the --atexit=no
from Kamailio command line.
See note on atexit
in TLS module "Overview".
doc/
subfolder, the README file is autogenerated)I'm using tls
module along with some other modules. On Kamailio termination there are a lot of "freeing already freed pointer" messages from qm_free()
. Also there may be a corrupted memory report (followed by abort()
) from qm_debug_check_frag()
.
I'm aware of --atexit=no
required for tls
, and Kamailio is indeed started as kamailio --atexit=no -m 16 -n 1 -w . -f some.cfg
.
The tls
module is loaded and configured something like this:
disable_core_dump=no
debug=2
memdbg=2
# mem_safety=0
enable_tls=yes
listen=tls:127.0.0.1:5060
mpath="lib64/kamailio/modules"
loadmodule "tls.so"
modparam("tls", "init_mode", 1)
modparam("tls", "config", "tls.cfg");
loadmodule "snmpstats.so"
modparam("snmpstats", "sipEntityType", "proxyServer")
modparam("snmpstats", "snmpgetPath", "/usr/bin/")
modparam("snmpstats", "snmpCommunity", "MySNMPComunity")
modparam("snmpstats", "snmpVersion", "2c")
loadmodule "xlog.so"
route {
xlog("L_NOTICE", "Hello\n");
}
Running Kamailio and then stopping it with SIGTERM
yields the following.
Some blocks of shared memory are allocated by the main process (PID 62575). E.g., one of the blocks:
0(62575) INFO: <core> [core/mem/q_malloc.c:429]: qm_malloc(): qm_malloc(0x7facc5dc0000, 8) returns address 0x7facc5e55810 frag. 0x7facc5e557d8 (size=8) on 1 -th hit
On termination, this address is freed by another process (PID 62583). Somewhere after "sig_usr(): signal 15 received" message there's the following entry in the log:
5(62583) INFO: <core> [core/mem/q_malloc.c:495]: qm_free(): qm_free(0x7facc5dc0000, 0x7facc5e55810), called from tls: tls_init.c: ser_free(400)
Then later the same address is freed again, by the main process (PID 62575). That's due to explicit call to OPENSSL_cleanup()
from tls_h_mod_destroy_f()
in tls
module:
0(62575) INFO: tls [tls_init.c:1063]: tls_h_mod_destroy_f(): executing openssl v1.1+ cleanup
0(62575) INFO: <core> [core/mem/q_malloc.c:495]: qm_free(): qm_free(0x7facc5dc0000, 0x7facc5e55810), called from tls: tls_init.c: ser_free(400)
0(62575) CRITICAL: <core> [core/mem/q_malloc.c:535]: qm_free(): BUG: freeing already freed pointer (0x7facc5e55810), called from tls: tls_init.c: ser_free(400), first free tls: tls_init.c: ser_free(400) - ignoring
It depends on initial conditions (which modules are loaded, what is the configuration, etc.), but sometimes qm_debug_check_frag()
detects memory corruption and calls abort()
:
0(62575) CRITICAL: <core> [core/mem/q_malloc.c:126]: qm_debug_check_frag(): BUG: qm: fragm. 0x7facc5e891e0 (address 0x7facc5e89218) beginning overwritten (7facc5e85498)! Memory allocator was called from tls: tls_init.c:400. Fragment marked by :140376711102467. Exec from core/mem/q_malloc.c:526.
The output of kamcmd core.ps
suggests that the offending process (PID 62583) is related to SNMP:
62575
main process - attendant
…
62583
SNMP AgentX
The "SNMP AgentX" process in snmpstats
overrides some signal handlers (including the SIGTERM
one) and calls exit()
:
/*! Creates a child that will become the AgentX sub-agent. The child will
* insulate itself from the rest of Kamailio by overriding most of signal
* handlers. */
void agentx_child(int rank)
{
…
/* Setup a SIGTERM handler */
sigfillset(&new_sigterm_handler.sa_mask);
new_sigterm_handler.sa_flags = 0;
new_sigterm_handler.sa_handler = sigterm_handler;
sigaction(SIGTERM, &new_sigterm_handler, NULL);
…
}
static void sigterm_handler(int signal)
{
/* Just exit. The master agent will clean everything up for us */
exit(0);
}
Looks like this exit()
triggers an extra call to OPENSSL_cleanup
, implicitly armed by OpenSSL itself on startup. So, the OpenSSL cleanup gets called twice.
As for now I've fixed the issue by replacing this exit(0)
with ksr_exit(0)
which respects the --atexit=no
command line option. But I wonder is it a right way to do it.
As far as I can see, code in src/modules/
ignores ksr_exit()
and uses plain exit()
. Is it for a reason? Shouldn't modules also exit with ksr_exit
?
https://github.com/kamailio/kamailio/pull/3993
(2 files)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.