2010/1/20 Vasanta <[email protected]>
> Can some valgrind expert analyze those logs, looklike malloc happening in
> libusb, which are not freed.
>
>
>
>
>
>
> On Wed, Jan 20, 2010 at 2:48 PM, Vasanta <[email protected]> wrote:
>
>> I ran again, this time it points to maloc(), Is this makes sense fro
>> memory leak?.
>>
>>
Of course it is malloc()... but the real question is who is calling malloc()
and better, who is loosing track of the memory returned by malloc.
Let me give an example (although I am sure these things are clearly
documented in the valgrind manual):
char * ptr = 0; // Global pointer
f() {
ptr = malloc(1024); // Allocate here
}
g() {
ptr = 0;
}
main() {
f();
// No bytes lost now since ptr is still pointing to it
g(); // Now this causes a memory leak since nothing is pointing to the
1024 bytes and the memory can never be free()d
}
In this case the output of valgrind will indicate that the memory allocated
by malloc() in f() is lost when the program exits.
As you can clearly see, the problem is not in f() but rather in g(). And for
sure, malloc() is not the problem.
Hopes this helps,
Bram.
------------------------------------------------------------------------------
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
