valgrind-users

[Valgrind-users] Memcheck and on-the-fly memory leak detection.

[Ehab A. <eha...@gm...>]

Hello,

I have looked at Memcheck and found out that it detects memory leaks
*after* finishing executing the guest application (i.e.no memory leak is
detected as soon the last reference to the allocated memory chunk is out of
scope). Is that right or did I miss something?

Thanks.

Re: [Valgrind-users] Memcheck and on-the-fly memory leak detection.

[David C. <dcc...@ac...>]

On 11/28/2011 12:42 PM, Ehab Ababneh wrote:
> Hello,
>
> I have looked at Memcheck and found out that it detects memory leaks 
> *after* finishing executing the guest application (i.e.no 
> <http://i.e.no/> memory leak is detected as soon the last reference to 
> the allocated memory chunk is out of scope). Is that right or did I 
> miss something?
>
> Thanks.
>

That is correct.  Memcheck is not a garbage collection system and does 
not count memory references dynamically.  That would slow down your 
program even more.  There are many ways in which references to memory 
can be "lost", such as storing a new value in a pointer variable, and 
without reference counts every one of these ways would trigger a full 
memory scan.  In many applications, most memory is not released when 
execution exits some scope; instead it is passed from module to module.  
Thus there would not be much advantage to a scan every time you return 
from a function, restart a loop iteration, etc.

-- 
     David Chapman         dcc...@ac...
     Chapman Consulting -- San Jose, CA

Re: [Valgrind-users] Memcheck and on-the-fly memory leak detection.

[WAROQUIERS P. <phi...@eu...>]

 
> That is correct.  Memcheck is not a garbage collection system 
> and does not count memory references dynamically.  That would 
> slow down your program even more.  There are many ways in 
> which references to memory can be "lost", such as storing a 
> new value in a pointer variable, and without reference counts 
> every one of these ways would trigger a full memory scan.  In 
> many applications, most memory is not released when execution 
> exits some scope; instead it is passed from module to module. 
>  Thus there would not be much advantage to a scan every time 
> you return from a function, restart a loop iteration, etc.

Note that at work, we have several thousands of small regression tests
but which have to run on a system which takes several minutes
to start. So, the system is started once, and a leak search
is done between each test (without stopping the system).
A "delta" leak search is done, showing the new leaks since the last
search. This means we have the leaks created by each test.
("delta" leak is a Valgrind 3.7.0 feature).

Leak search can be programmed using the client requests available
from memcheck.h.
Alternatively (again with Valgrind 3.7.0), you can trigger a leak
search from gdb (using the Valgrind gdbserver) or from the shell
(using vgdb command).

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.