Thanks for your answer Adam. Actually we are not using malloc and free at
all but only new() and delete().
I will check the delete (object) hint below but from what I remember we
never new() arrays of objects.
In the printout of the malloc_g ( as a result of malloc_dump_unreferenced()
or something ) there are no leaks detected
BUT there are more and more ARENAs comming up. Each 16k or 32k large. Do you
know what these ARENAs mean? Do they indicate physical memory
that is mapped into the process space?
I just got an idea that maybe mmap() is used by some code (not mine) to get
memory into the process space (to bypass malloc for whatever reason).
Whould that show up as a new ARENA? Maybe just a wild guess?
“Adam Mallory” <firstname.lastname@example.org> wrote in message
“Mats Pettersson” <> email@example.com> > wrote in message
news:a26nvl$hba$> firstname.lastname@example.org> …
We have had a memory leak for quiet a while in our application. We have
via the use of the malloc_g library, made it very clear to us that the
is NOT due to incorrect use of malloc/calloc/realloc/new etc.
What does your definition of incorrect use include? Do you mean you have
free()/delete() for every malloc()/new()? (if so, there are many other
to leak memory).
Does anyone know of something else that can cause leaks in a process. I
also say that we are NOT using threads. We are though using C++/STL,
and mqueue (mq_send, mq_receive etc).
Off the top of my head, malloc/free() ing an object is a bad idea in C++.
Perhaps you’re free()ing a structure or delete()ing a list which still has
allocated members. When delete()ing an array in C++ you need to remember
do a delete(object) - this one is easy to miss. I’m sure there are many
others I haven’t mentioned - but it’s somewhere to start.
Have you narrowed the scope down from you app, to a specific area or time
frame when the leak occurs?
QNX Software Systems Ltd.
[ > email@example.com > ]
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> firstname.lastname@example.org