In message 1B07E47F.20010506131757.FOO-5823.frank@g-n-u.de Frank Heckenbach writes:
Simply using the unit HeapMon should show some report about non-released pointers at the end of the program. The unit also provides a function to generate such a report at an arbitrary point during a program run and to an arbitrary file.
The report contains the caller address (which can be turned to source lines using addr2line) which might help find the leaks.
Frank,
Thank you, I've now downloaded version 20010512, and tried the new HeapMon.
It is very useful.
Unfortunately, what it seems to show is that my problem is not with non-released pointers.
The general structure of this program is (in a sort-of pseudo-code):
begin allocate_shared_memory;
use HeapMon to report non-released pointers; (*1*)
while true begin wait for a message on a System V IPC message queue; process the message; (* a lot of code, usually involves writing a new file*) use HeapMon to report non-released pointers; (*2*) end;
(*never gets here - program is terminated by a signal(2) from some other process*) end.
I see no difference between the report from HeapMon at point (*1*) and the reports from HeapMon that are generated after each message is processed at point (*2*). Each of them shows the 4 separate pieces of memory that are allocated by new in allocate_shared_memory.
However, as the program runs (under Linux) I see the Vsize (and RSS) increasing.
I suspect that my problem is allocation within routines from the C run-time libraries that my low-level code is calling, or (possibly) allocation within the GPC RTS.
My question now is, what else can I try to see what is being allocated and not released at these lower levels. Is electric fence the tool to use (and if so, how well does it work with GPC)?
Anyone any other suggestions?