Thanks Bram. Let me look all routines closely.
On Wed, Jan 20, 2010 at 4:07 PM, Bram De Wachter <[email protected]> wrote:
>
>
> 2010/1/20 Vasanta <[email protected]>
>
>> Thanks for that, I have prog here which points to malloc, I can see buf
>> was pointer, allocated memory by malloc, it gets filled, but the last few
>> lines of code, doesnot free that, also it does fee priv->con... and then it
>> assigns, looks not correct.
>>
>>
>>
> That code looks ok. The only obvious malloc I see is line 629, and on any
> exit path, it either gets freed or is returned (636 or 642).
> Apparently the __device_priv(dev) call may allocate memory in which case
> it must be freed to avoid memory leak (642).
>
> Code looks perfectly legit (in case the call to __device_priv(dev) attaches
> somehow the priv structure to the dev parameter, which can not be told from
> the code you give)
>
> Again, if you pay closer attention to my previous example: the error is in
> the g() function by analogy: here you show only the f() function. The
> question you should ask is : the priv->config_descriptor is probably
> attached to the dev parameter. The caller of this function is maybe
> overwriting it without freeing it.
>
> There is no magical solution "hey look at this piece of code, and tell me
> what is wrong". Memory leaks rarely happen at one place, but mostly happen
> due to a combination of several things.
>
> Happy hunting,
> 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
