>-----Original Message-----
>From: Nicholas Nethercote [mailto:n.netherc...@gmail.com]
>Sent: Friday 11 September 2009 00:17
>To: Cristian Todor
>Cc: valgrind-users@lists.sourceforge.net
>Subject: Re: [Valgrind-users] Fw: Massif for LWP
>
>On Thu, Sep 10, 2009 at 11:34 PM, Cristian Todor
><acto...@yahoo.com> wrote:
>>> I've been searching around for a tool that cou;d help me
>>> detect a possible memory leak in the piece of software I'm
>>> working on.
>>> I stumbled upon valgrind's massif, but could not figure out
>>> how to get heap stats on a per-thread basis (LWP number)
>>> rather than on the whole process.
>>> Is this even possible ?
>
>No. You could modify Massif to do it with some effort, though.
An alternative would be to modify callgrind or memcheck.
In a corner, I started to modify callgrind to track the memory usage
in addition to what callgrind already tracks (instructions and similar).
Callgrind (and its associated Kcachegrind) can already separate data per
thread. This work has been discussed with Josef, who gave several
comments
(implying some non-trivial work for which I had no time yet).
This would allow to look at heap statistics (which stack trace allocated
what memory) per thread.
However, I do not understand why you need such a feature to search for
memory
leak. Whatever the thread that is allocating the "lost/leaked" memory,
memcheck should be able to point at which piece of code allocated the
memory
that has been lost. It is not clear why you need the thread id in this
context.
Can you explain why you need per-thread statistics to search for a
memory leak ?
Maybe it is not a pure memory leak you are searching for (i.e. "lost the
last
pointer to memory") but rather "who is allocating memory and keeping
pointers to
it while it should have released it instead" ?
Even in this case, again, the stack trace (without thread id) should be
enough to guess what is wrong in the code.
If really the thread id is needed, then I guess a simpler approach could
be to
include the thread id of the calling thread in the "stack trace"
maintained
by memcheck (e.g. when a new arg --separate-threads would be given).
With this to be developped feature
and/or the usual features of memcheck
and/or what I proposed in
http://bugs.kde.org/show_bug.cgi?id=206802
you should be able to pinpoint relatively quickly where is the guilty
that
selfishly allocates all that memory and keeping pointers to it
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.
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
