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?
David James wrote:
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.
The latter should also be caught be HeapMon, the former not -- you might be able to change them to Pascal allocation:
void *_p_new (size_t); void _p_dispose (const void *); void _p_gpc_reallocmem (void **, size_t);
Note: _p_gpc_reallocmem has different arguments than realloc in C.
NOTE: When using HeapMon etc., each pointer allocated with _p_new must be freed only with _p_dispose. Using free on such a pointer will corrupt the data used by HeapMon.
Another possibility: I recently read an article in the German c't magazin about glibc. If you're using it (most Linux systems do by now), you might be able to use its debugging facilities (look for mtrace() and $MALLOC_TRACE -- I hope there's something about it in the docs or on the net).
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)?
efence works well with GPC. It checks errors such as using unintialized pointers (in some cases), using freed memory, bounds overflow in heap allocated memory, etc. -- might not be exactly what you need here.
Frank
On Tue, 15 May 2001, Frank Heckenbach wrote:
[..]
Another possibility: I recently read an article in the German c't magazin about glibc. If you're using it (most Linux systems do by now), you might be able to use its debugging facilities (look for mtrace() and $MALLOC_TRACE -- I hope there's something about it in the docs or on the net).
Try info glibc. There's a node called "Allocation Debugging" with 4 sub-nodes.
Don't know about earlier releases, but it is in glibc-2.2.2 release.
Russ
-
david＠tcs01.demon.co.uk -
Frank Heckenbach -
Russ Whitaker