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
--
Daniel-Constantin Mierla -
http://www.asipto.com
http://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -
http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -
http://asipto.com/u/katu