Hello all, (all this is happening on a Suse 7.3 machine 2.4.10 kernel) I am trying to debug an application that is eating memory, I've been using memprof and efence but no luck so far. The really weird thing is that the memory eaten by the program is not released after killing the program. Judging from a few articles i found this should mean that it is shared memory, however, we don't explicitly use shared memory. What i see is that if the program is running and i start 'top' the total amount of memory used is growing but there is no task that is using a lot of memory after a while. In the long run our program stops to function due to memory shortage, the only way out is a reset. memprof doesn't indicate anything. efence doesn't indicate errors. All calls to malloc and free are in a wrapper that makes tracking allocation easy from within the program. (wrappers are well tested). So what happens to my memory ?? Grtz Dries Pruimboom -- 01110111 01110111 01110111 00101110 01110000 01110010 01110101 01101001 01101101 01100010 01101111 01101111 01101101 00101110 01110100 01101011 <End of message>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 24 Sep 2003 14:35:04 -0700 dries <dries@irssystems.nl> wrote:
Hello all,
(all this is happening on a Suse 7.3 machine 2.4.10 kernel)
I am trying to debug an application that is eating memory, I've been using memprof and efence but no luck so far. The really weird thing is that the memory eaten by the program is not released after killing the program. Judging from a few articles i found this should mean that it is shared memory, however, we don't explicitly use shared memory.
What i see is that if the program is running and i start 'top' the total amount of memory used is growing but there is no task that is using a lot of memory after a while. In the long run our program stops to function due to memory shortage, the only way out is a reset.
memprof doesn't indicate anything. efence doesn't indicate errors. All calls to malloc and free are in a wrapper that makes tracking allocation easy from within the program. (wrappers are well tested).
So what happens to my memory ?? Does it use mmap(2). Also, possibly some libraries are loaded and not unloaded immediately.
Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/cZXm+wA+1cUGHqkRApcMAJwK0vT7BqsBeIsh+DfjXzWBTXqwdACghNlO fY4g71QxofwlnZ8vazQ4Sao= =Kdu+ -----END PGP SIGNATURE-----
Jerry Feldman wrote :
Does it use mmap(2). Also, possibly some libraries are loaded and not unloaded immediately. - --
It doesn't explicitly use mmap, however a library function could use it internally without me knowing. We are also not loading shared libraries ourself, if the system doesn't unload the libs immediately it would if there is going to be a memory shortage isn' it ?. Do you know of any tools to check mmap-ed memory ?? thanx Dries <End of message>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 24 Sep 2003 15:09:18 -0700 dries <dries@irssystems.nl> wrote:
Jerry Feldman wrote :
Does it use mmap(2). Also, possibly some libraries are loaded and not unloaded immediately.- --
It doesn't explicitly use mmap, however a library function could use it internally without me knowing.
We are also not loading shared libraries ourself, if the system doesn't unload the libs immediately it would if there is going to be a memory shortage isn' it ?.
Do you know of any tools to check mmap-ed memory ?? I don't know if valgrind does, but you might consider it to help look for leaks in your application. (Actually, Purify does check mmaped memory, but it is a commercial product).
- -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) iD8DBQE/cZ3u+wA+1cUGHqkRAhCoAJ92bgB6NbE8CIExXrgpSjTPLuFSrwCbBJQw u7ee/C8HOD2UcnUoXv20dmo= =Vcqi -----END PGP SIGNATURE-----
participants (2)
-
dries -
Jerry Feldman