On Thu, Nov 18, 2004 at 01:34:46PM -0300, Jorge Arellano Cid wrote:
[...] I decided to cut glib out of the problem, then developed a test program and did some research. *Very* interesting results came out of it.
[...]
[Lars wrote:] If the threads are allocating of a public heap it might not be possible to reclaim/remap the heap so it will look as if a lot of memory is allocated. There is a similar 'bug' in the C++ standard that means that memory allocated by objects might never be reclaimed under some circumstances.
Yes it look like this kind of problem.
I DO NOT now if this is related to the problem, but it sounds a bit similar (I suppose you have tried running the whole lot under valgrind ?)
I cut glib out and made a test program (attached), that matches mallocs and frees trivially.
The results were amazing:
compile the program with:
gcc pth_mem.c -o pth_mem -lpthread
run it like this:
./pth_mem <j|d|cd>
and observe the memory footprint from another terminal with:
while [ 1 ]; do ps aux | grep [p]th_mem; sleep 4; done
Has anyone had the opportunity to run the test program under Solaris? This is an interesting test because Solaris has its own threads implementation. I'd expect the detached pthreads test not to leak memory on Solaris. BTW, the new threads-based dpi server is in the CVS now. This fixes a critical race with large files that linked lots of instances of a minor image (a bullet for instance). It worked OK with my tests (up to a 2MB page), uses joinable threads, and didn't show any leaks while testing. Strange no one reported this bug before... Well I guess almost nobody writes large HTML pages these days, as the very big browsers will surely have a hard time with them! :-) -- Cheers Jorge.-