I'm testing with this kamailio version: $ kamcmd version kamailio 5.5.4 (x86_64/linux) 54c9df
on: $ cat /etc/issue Debian GNU/Linux 11 \n \l
with: $ openssl version OpenSSL 1.1.1k 25 Mar 2021
Whenever I start kamailio I get 3199 log lines like this:
2022-03-10T10:04:39.700676+09:00 lab002201-flip-server /usr/local/src/git/kamailio-5.5/src/kamailio[261703]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f8eb57f7848), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring
I searched the issues at github and found: https://github.com/kamailio/kamailio/issues/2560 https://github.com/kamailio/kamailio/issues/2912
So I tried to start kamailio with --atexit=no but those logs remain.
With and without using --atexit=no there is no crash and all my tests are OK. But should I be worried to put this in production?
Hello,
that function is used inside the libssl, looks like the version in OS has some double free somewhere -- it could be also in other libs (needed by kamailio modules) that uses libssl, like libcurl via http client modules.
Double frees are safe for kamailio, but behind can be another issue that leads to it and that can have unexpected side effects. So it is not a simple answer here. Maybe you can try with other libssl version or try to unload kamailio modules that might use libssl independently of tls module.
Cheers, Daniel
On 10.03.22 02:24, mayamatakeshi wrote:
I'm testing with this kamailio version: $ kamcmd version kamailio 5.5.4 (x86_64/linux) 54c9df
on: $ cat /etc/issue Debian GNU/Linux 11 \n \l
with: $ openssl version OpenSSL 1.1.1k 25 Mar 2021
Whenever I start kamailio I get 3199 log lines like this:
2022-03-10T10:04:39.700676+09:00 lab002201-flip-server /usr/local/src/git/kamailio-5.5/src/kamailio[261703]: CRITICAL: <core> [core/mem/q_malloc.c:519]: qm_free(): BUG: freeing already freed pointer (0x7f8eb57f7848), called from tls: tls_init.c: ser_free(323), first free tls: tls_init.c: ser_free(323) - ignoring
I searched the issues at github and found: https://github.com/kamailio/kamailio/issues/2560 https://github.com/kamailio/kamailio/issues/2912
So I tried to start kamailio with --atexit=no but those logs remain.
With and without using --atexit=no there is no crash and all my tests are OK. But should I be worried to put this in production?
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
On 11.03.22 11:14, Daniel-Constantin Mierla wrote:
Double frees are safe for kamailio
until they are not, i.e. when (not if) something else manages to allocate the memory in question before the second "free" comes along, you have a problem.
How to proceed: replace the
shm_free(ptr);
at line 323 of tls_init.c with its macro expansion, i.e.
_shm_root.xfree(_shm_root.mem_block, (p), "shm", fname, fline, "tls")
(or something along these lines) so that you get some idea of where these "shm_free" calls originate.
This probably should also be done for the calls to malloc and realloc. There's no good reason to throw away the debug information.
On 11.03.22 11:34, Matthias Urlichs wrote:
On 11.03.22 11:14, Daniel-Constantin Mierla wrote:
Double frees are safe for kamailio
until they are not,
By cutting only the part you want and comment only around it, then you start to misinform. If you want to add value for a conversation, keep the whole context.
Double free is a safe operation in Kamailio, what leads to it can be an issue, like I said in my "full" email previously.
Cheers, Daniel
i.e. when (not if) something else manages to allocate the memory in question before the second "free" comes along, you have a problem.
How to proceed: replace the
shm_free(ptr);
at line 323 of tls_init.c with its macro expansion, i.e.
_shm_root.xfree(_shm_root.mem_block, (p), "shm", fname, fline, "tls")
(or something along these lines) so that you get some idea of where these "shm_free" calls originate.
This probably should also be done for the calls to malloc and realloc. There's no good reason to throw away the debug information.
-- -- regards -- -- Matthias Urlichs
Kamailio - Users Mailing List - Non Commercial Discussions
- sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
-
Daniel-Constantin Mierla -
Matthias Urlichs -
mayamatakeshi