Well, of course, I can just attach a gdb.

The problem is that it's a live site. But it's probably not all that live right now. :-)

/ Per Hedbor ()

Previous text:

2004-09-27 18:05: Subject: memory leak in oracle module

---

Is there an easy way to inspect the heap to find out what kind of data that's kept in memory? I.e., SQL queries, HTML fragments, image bitmaps etc? If it's close to 2 GB I guess you don't have to worry about scanning for allocated memory addresses since almost any will do.

/ Jonas Walldén

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.

/ Per Hedbor ()

Previous text:

2004-09-27 18:22: Subject: memory leak in oracle module

---

Well, of course, I can just attach a gdb.

The problem is that it's a live site. But it's probably not all that live right now. :-)

/ Per Hedbor ()

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