QNX 6.1, patch A
We have had a memory leak for quiet a while in our application. We have now,
via the use of the malloc_g library, made it very clear to us that the leak
is NOT due to incorrect use of malloc/calloc/realloc/new etc.
We can see that the process is leaking by using psin and looking in the DATA
column for the process.
Does anyone know of something else that can cause leaks in a process. I can
also say that we are NOT using threads. We are though using C++/STL, TCP/IP
and mqueue (mq_send, mq_receive etc).
regards, Mats P
“Mats Pettersson” <mats.pettersson@wavium.se> wrote in message
news:a26nvl$hba$1@inn.qnx.com…
We have had a memory leak for quiet a while in our application. We have
now,
via the use of the malloc_g library, made it very clear to us that the
leak
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 a
free()/delete() for every malloc()/new()? (if so, there are many other ways
to leak memory).
Does anyone know of something else that can cause leaks in a process. I
can
also say that we are NOT using threads. We are though using C++/STL,
TCP/IP
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 to
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?
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
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?
Best regards,
/MP
“Adam Mallory” <amallory@qnx.com> wrote in message
news:a271pu$p0n$1@nntp.qnx.com…
“Mats Pettersson” <> mats.pettersson@wavium.se> > wrote in message
news:a26nvl$hba$> 1@inn.qnx.com> …
We have had a memory leak for quiet a while in our application. We have
now,
via the use of the malloc_g library, made it very clear to us that the
leak
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
a
free()/delete() for every malloc()/new()? (if so, there are many other
ways
to leak memory).
Does anyone know of something else that can cause leaks in a process. I
can
also say that we are NOT using threads. We are though using C++/STL,
TCP/IP
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
to
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?
–
Cheers,
Adam
QNX Software Systems Ltd.
[ > amallory@qnx.com > ]
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
“Mats Pettersson” <mats.pettersson@wavium.se> wrote in message
news:a2767v$r0p$1@inn.qnx.com…
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?
malloc() using mmap when it needs to map in more heap space. Once it’s
mmap’ed in a new block (requested size, rounded up to page size blocks) of
memory, it’s removed from the overall free pool. When you start free’ing
memory it won’t result in munmap() calls (performance reasons), so your heap
will remain the same size until your process ends.
–
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>