How about building pike --with-dmalloc? Although that doesn't look like it actually uses dmalloc; it's more of an internal malloc tracer for pike internals.
Pikes dmalloc typically covers all C modules in pike since it's active in all files that are compiled with the pike headers. (I've also seen some kind of hack that looks like it replaces the libc malloc functions using dlopen stuff, but I've never used it.) So I'd say there's a good chance that pike dmalloc would track the leaks, but it's slow of course.
/ Martin Stjernholm, Roxen IS
Previous text:
2004-09-27 19:43: Subject: Re: memory leak in oracle module
In the last episode (Sep 27), Per Hedbor () @ Pike (-) developers forum said:
Nothing that can be easily detected as anything 'non-normal' in the memory. No large heaps of SQL queries or replies as far as I can see.
Nor any other easily detectable strings in the 1000 different positions I tried.
How about building pike --with-dmalloc? Although that doesn't look like it actually uses dmalloc; it's more of an internal malloc tracer for pike internals.
Or, try installing dmalloc, export LD_PRELOAD=/usr/local/lib/libdmalloc.so, run this to enable leak checking:
eval `dmalloc -b -l /tmp/dmalloc.log -p log-non-free`
then start roxen. If you do a clean shutdown, you should then end up with a list of all leaked memory in /tmp/dmalloc.log. When dmalloc is preloaded like that instead of compiled in, you only get hex addresses instead of function names, but if you run "gcore" to generate a coredump of the pike process just before you shutdown, you can load that info gdb and run "info line *(0x280579fe)" to get the function corresponding to ra=0x280579fe, for example.
-- Dan Nelson dnelson@allantgroup.com
/ Brevbäraren