This is actually the reason I moved the check for free(0) before the check of the memory address range. Someone reported on irc that libssl does free(0) causing core dump due to an internal abort() executed in qm_free(p), if p is less than minimum memory address (which was the case when p=0).
I think we can make it MDBG(...) in f_malloc.c, so it is printed only if one wants memory debug messages -- this memory manager is intended for production/stable releases, although in the past we did some releases with q_malloc.
In q_malloc.c maybe it should stay the same, being for troubleshooting reasons, to spot if we have free(0) inside our code.
You can go and update in f_malloc and backport, if it is a solution that is ok for you.
Cheers, Daniel
On 10/2/12 9:45 PM, Juha Heinanen wrote:
Daniel-Constantin Mierla writes:
Anyhow, I pushed a patch to master branch to print the file and line for free(0) when compiled with memdbg=1.
Try it to see if you get the details of free(0) location.
daniel,
thanks for the patch. i now got bunch of these at shutdown:
Oct 2 22:43:54 siika /usr/sbin/sip-proxy[5996]: WARNING: <core> [mem/q_malloc.c:442]: WARNING:qm_free: free(0) called from tls: tls_init.c: ser_free(298)
-- juha