|
From: Olivier C. <ol...@vu...> - 2010-10-13 01:25:26
|
Hi, When running my app (written in Vala, using libgee and libxml2), I can see that even after everything should have been freed, it's still using about 800MB of ram (under top and the gnome system monitor). I've tried to see what the source of the "leak" is using valgrind, but valgrind only sees 24MB of "possibly lost" memory. I was wondering if anyone would know what could be the source for the difference between top / g-s-m and valgrind ? Assuming valgrind is right (and the app is actually not really leaking), how could I force the OS to see that the memory usage is back to a regular level ? While running, the app will allocate up to 1.2GB of RAM, but all that is supposed to get freed. Thanks in advance, Olivier |
|
From: WAROQUIERS P. <phi...@eu...> - 2010-10-13 07:45:44
|
>of the "leak" is using valgrind, but valgrind only sees 24MB >of "possibly lost" memory. For what concerns the possibly lost, a bug has been recently fixed in 3.6.0 SVN. Before this fix, memcheck was giving a lot of "false possibly lost". See http://bugs.kde.org/show_bug.cgi?id=206600 >leaking), how could I force the OS to see that the memory >usage is back to a regular level ? On most OS (and at least on gnu/linux), libc malloc/free does not return (all of) the memory to the Operating System after free. Only big blocks are specially handled and are "fully" returned to the OS when free is called : big blocks are allocated using mmap, while smaller blocks are allocated using brk. (you might look at http://bugs.kde.org/show_bug.cgi?id=250101 which somewhat explores this in the framework of huge "unused" memory under valgrind). To my knowledge, there is nothing that can force to decrease the size of the "brk allocated" region used by malloc. ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |
|
From: Josef W. <Jos...@gm...> - 2010-10-13 11:55:06
|
On Wednesday 13 October 2010, WAROQUIERS Philippe wrote: > To my knowledge, there is nothing that can force to decrease the size > of the "brk allocated" region used by malloc. With enough swap space, that space always can be swapped out once and is never touched again (until reused). So you can argue that it should not influence system performance too much... Josef |
|
From: Oliver G. <ol...@gm...> - 2010-10-15 18:12:26
|
Have you tried running your app under Massif? That has helped me recently to track down a memory leak which was not visible in Valgrind/Memcheck but became clearly visible in Valgrind/Massif (the leak was caused by repeated setenv() calls, which apparently don't free any memory even if the env var is unset later). Am Dienstag, den 12.10.2010, 18:25 -0700 schrieb Olivier Chalouhi: > Hi, > > When running my app (written in Vala, using libgee and libxml2), I can see that even after everything should have been freed, it's still using about 800MB of ram (under top and the gnome system monitor). I've tried to see what the source of the "leak" is using valgrind, but valgrind only sees 24MB of "possibly lost" memory. > > I was wondering if anyone would know what could be the source for the difference between top / g-s-m and valgrind ? Assuming valgrind is right (and the app is actually not really leaking), how could I force the OS to see that the memory usage is back to a regular level ? > > While running, the app will allocate up to 1.2GB of RAM, but all that is supposed to get freed. > > Thanks in advance, > > Olivier > > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: WAROQUIERS P. <phi...@eu...> - 2010-10-18 14:13:52
|
>Have you tried running your app under Massif? That has helped me >recently to track down a memory leak which was not visible in >Valgrind/Memcheck but became clearly visible in Valgrind/Massif (the >leak was caused by repeated setenv() calls, which apparently don't free >any memory even if the env var is unset later). > Note also that you might also try the "gdbserver" patch, which provides an "incremental leak (or more precisely delta malloc-ed or delta free-d)" "leak search" functionality. (see http://bugs.kde.org/show_bug.cgi?id=214909 ) Philippe ____ This message and any files transmitted with it are legally privileged and intended for the sole use of the individual(s) or entity to whom they are addressed. If you are not the intended recipient, please notify the sender by reply and delete the message and any attachments from your system. Any unauthorised use or disclosure of the content of this message is strictly prohibited and may be unlawful. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of EUROCONTROL, unless it is confirmed by appropriately signed hard copy. Any views expressed in this message are those of the sender. |