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