|
From: Patrick O. <Pat...@in...> - 2004-08-18 12:13:52
|
Hi all, perhaps I am missing something obvious, but is there a possibility to print the address of a memory block which was leaked in the report of the leak? I'm using memcheck. I know that this would be impossible when --leak-resolution causes several leaks to be merged into one, but in my case there's just one block. Having that address and some debug output might make it easier to track down a memory leak. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. |
|
From: Tom H. <th...@cy...> - 2004-08-18 13:34:44
|
In message <1092831252.554.137.camel@debian>
Patrick Ohly <Pat...@in...> wrote:
> perhaps I am missing something obvious, but
> is there a possibility to print the address
> of a memory block which was leaked in the
> report of the leak? I'm using memcheck.
Not at the moment.
> I know that this would be impossible when
> --leak-resolution causes several leaks to
> be merged into one, but in my case there's
> just one block.
Even --leak-resolution=high will merge blocks allocated in
exactly the same place.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Patrick O. <Pat...@in...> - 2004-08-18 14:27:42
|
On Wed, 2004-08-18 at 15:34, Tom Hughes wrote: > In message <1092831252.554.137.camel@debian> > Patrick Ohly <Pat...@in...> wrote: > > > perhaps I am missing something obvious, but > > is there a possibility to print the address > > of a memory block which was leaked in the > > report of the leak? I'm using memcheck. > > Not at the moment. Can you point me in the right direction so that (when I find the time) I can provide a patch which does that? Would that be accepted into valgrind mainline? > > I know that this would be impossible when > > --leak-resolution causes several leaks to > > be merged into one, but in my case there's > > just one block. > > Even --leak-resolution=high will merge blocks allocated in > exactly the same place. Yep, but in my case it really was just one chunk. Sounds like "--leak-resolution=none" would be a good extension, too. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Software & Solutions Group Hermuelheimer Strasse 8a 50321 Bruehl Germany Tel: +49-2232-2090-30 Fax: +49-2232-2090-29 |
|
From: Eric E. <eri...@fr...> - 2004-08-18 15:13:25
|
Patrick Ohly wrote: >>>perhaps I am missing something obvious, but >>>is there a possibility to print the address >>>of a memory block which was leaked in the >>>report of the leak? I'm using memcheck. > > Can you point me in the right direction so that (when > I find the time) I can provide a patch which does that? > Would that be accepted into valgrind mainline? I don't see why exactly you need the address of leaked blocks, except if: - your program logs additional information associated to the blocks when allocating them, e.g. for a web browser: block at 0xXYZ allocated when requesting doc http://xxx/zzz - you have a tool which consolidates the valgrind log with your custom log, so you can identify exactly the context in which your program triggered the leak In that case, it would be clever to add support for user data association to the blocks, probably through a valgrind user call. The pairs (key,value) associated with each block would be dumped directly in Valgrind log. That way the mechanism would be generic. This could also help tools like massif classifying the allocations based on user-defined contexts. Could you provide a detailed example (if different from what I supposed), so a generic way of solving that problem could be designed and implemented into Valgrind in the future ? For now, if you are in a hurry, you can have a look at memcheck/mac_leakcheck.c, and: - Add an address member in LossRecord structure - tweak MAC_(pp_LeakError) so as to print it - tweak MAC_(do_detect_memory_leaks): - do not compare blocks together - initialize the address in the LossRecord struct (But such a change is likely to be never accepted in Valgrind, since it is really kludgy !) Cheers -- Eric |
|
From: Patrick O. <Pat...@in...> - 2004-08-19 06:27:59
|
On Wed, 2004-08-18 at 17:12, Eric Estievenart wrote: > Patrick Ohly wrote: > > >>>perhaps I am missing something obvious, but > >>>is there a possibility to print the address > >>>of a memory block which was leaked in the > >>>report of the leak? I'm using memcheck. > > > > Can you point me in the right direction so that (when > > I find the time) I can provide a patch which does that? > > Would that be accepted into valgrind mainline? > > I don't see why exactly you need the address of > leaked blocks, except if: > - your program logs additional information associated > to the blocks when allocating them, e.g. for a web browser: > block at 0xXYZ allocated when requesting doc http://xxx/zzz This is exactly what I have. > For now, if you are in a hurry, Not any more because after some more searching I found the reason for the leak, and ... > you can have a look > at memcheck/mac_leakcheck.c, and: > - Add an address member in LossRecord structure > - tweak MAC_(pp_LeakError) so as to print it > - tweak MAC_(do_detect_memory_leaks): > - do not compare blocks together > - initialize the address in the LossRecord struct > > (But such a change is likely to be never accepted in > Valgrind, since it is really kludgy !) ... as it wouldn't be considered generally useful I won't bother to change it. -- Best Regards Patrick Ohly Senior Software Engineer Intel GmbH Software & Solutions Group Hermuelheimer Strasse 8a 50321 Bruehl Germany Tel: +49-2232-2090-30 Fax: +49-2232-2090-29 |