|
From: Bill M. <wm...@ci...> - 2005-08-16 17:30:45
|
Hi, I'm using 3.0.0 and would like to know how I can get the address of the memory that the leak check displays at the end of execution. I'm using: valgrind --tool=memcheck --leak-check=full --leak-resolution=high --trace-children=yes --show-reachable=yes <command line> It works brillantly, and display lines like: 2048 bytes in 1 blocks are definately lost in loss record 6 of 6 at 0x1B90088D: malloc (vg_replace_malloc.c:149) by 0x1b9C4e6d: ???? by ... Is there a way to tell what address the block is at ? In my program, the address used will malloc many, many times, with the memory following different paths - by knowing the address, I can figure out where it is going using printfs. Any other ideas ? I also noticed that it will display an error message like: 0 bytes in 1 block after a malloc of 0. I've removed the malloc of 0, but wonder if this is a valid message. Thanks, Bill May |
|
From: Bob D. <bd...@sr...> - 2005-08-16 17:38:24
|
Sounds like a job for gdb. You can set a breakpoint prior to the malloc, and then print the address of the pointer. On Tue, 2005-08-16 at 10:30 -0700, Bill May wrote: > Hi, > > I'm using 3.0.0 and would like to know how I can get the > address of the memory that the leak check displays at the > end of execution. > > I'm using: > valgrind --tool=memcheck --leak-check=full --leak-resolution=high > --trace-children=yes --show-reachable=yes <command line> > > It works brillantly, and display lines like: > > 2048 bytes in 1 blocks are definately lost in loss record 6 of 6 > at 0x1B90088D: malloc (vg_replace_malloc.c:149) > by 0x1b9C4e6d: ???? > by ... > > Is there a way to tell what address the block is at ? In my program, > the address used will malloc many, many times, with the memory following > different paths - by knowing the address, I can figure out where it > is going using printfs. > > Any other ideas ? > > I also noticed that it will display an error message like: > 0 bytes in 1 block after a malloc of 0. I've removed the malloc > of 0, but wonder if this is a valid message. > > Thanks, > Bill May > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Bill M. <wm...@ci...> - 2005-08-16 17:56:35
|
Bob, That would be great for 1 or 2 mallocs. I'm talking about thousands occurring every second. Bill Bob Dusek wrote: > Sounds like a job for gdb. You can set a breakpoint prior to the > malloc, and then print the address of the pointer. > > On Tue, 2005-08-16 at 10:30 -0700, Bill May wrote: > >>Hi, >> >>I'm using 3.0.0 and would like to know how I can get the >>address of the memory that the leak check displays at the >>end of execution. >> >>I'm using: >>valgrind --tool=memcheck --leak-check=full --leak-resolution=high >> --trace-children=yes --show-reachable=yes <command line> >> >>It works brillantly, and display lines like: >> >>2048 bytes in 1 blocks are definately lost in loss record 6 of 6 >> at 0x1B90088D: malloc (vg_replace_malloc.c:149) >> by 0x1b9C4e6d: ???? >> by ... >> >>Is there a way to tell what address the block is at ? In my program, >>the address used will malloc many, many times, with the memory following >>different paths - by knowing the address, I can figure out where it >>is going using printfs. >> >>Any other ideas ? >> >>I also noticed that it will display an error message like: >>0 bytes in 1 block after a malloc of 0. I've removed the malloc >>of 0, but wonder if this is a valid message. >> >>Thanks, >>Bill May >> >> >>------------------------------------------------------- >>SF.Net email is Sponsored by the Better Software Conference & EXPO >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Bob D. <bd...@sr...> - 2005-08-16 18:21:39
|
Yeah. I'm green. Sorry for the noise. You may find some good stuff in the Variants and Patches portion of the Web site. On Tue, 2005-08-16 at 10:56 -0700, Bill May wrote: > Bob, > > That would be great for 1 or 2 mallocs. I'm talking about thousands > occurring every second. > > Bill > > Bob Dusek wrote: > > Sounds like a job for gdb. You can set a breakpoint prior to the > > malloc, and then print the address of the pointer. > > > > On Tue, 2005-08-16 at 10:30 -0700, Bill May wrote: > > > >>Hi, > >> > >>I'm using 3.0.0 and would like to know how I can get the > >>address of the memory that the leak check displays at the > >>end of execution. > >> > >>I'm using: > >>valgrind --tool=memcheck --leak-check=full --leak-resolution=high > >> --trace-children=yes --show-reachable=yes <command line> > >> > >>It works brillantly, and display lines like: > >> > >>2048 bytes in 1 blocks are definately lost in loss record 6 of 6 > >> at 0x1B90088D: malloc (vg_replace_malloc.c:149) > >> by 0x1b9C4e6d: ???? > >> by ... > >> > >>Is there a way to tell what address the block is at ? In my program, > >>the address used will malloc many, many times, with the memory following > >>different paths - by knowing the address, I can figure out where it > >>is going using printfs. > >> > >>Any other ideas ? > >> > >>I also noticed that it will display an error message like: > >>0 bytes in 1 block after a malloc of 0. I've removed the malloc > >>of 0, but wonder if this is a valid message. > >> > >>Thanks, > >>Bill May > >> > >> > >>------------------------------------------------------- > >>SF.Net email is Sponsored by the Better Software Conference & EXPO > >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > >>_______________________________________________ > >>Valgrind-users mailing list > >>Val...@li... > >>https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > |
|
From: Tom H. <to...@co...> - 2005-08-16 18:20:22
|
In message <430...@ci...>
Bill May <wm...@ci...> wrote:
> I also noticed that it will display an error message like:
> 0 bytes in 1 block after a malloc of 0. I've removed the malloc
> of 0, but wonder if this is a valid message.
That is entirely valid assuming that you didn't free it.
The C standard allows two possible behaviours for a zero byte
malloc - either it can return null (which can be safely freed as
freeing null is guaranteed to work) or it can return a unique
address of a block with no memory associated.
Hence zero size mallocs need to be freed or you may be leaking
resources on some implementations.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-16 18:56:38
|
On Tue, 16 Aug 2005, Bill May wrote: > I'm using 3.0.0 and would like to know how I can get the > address of the memory that the leak check displays at the > end of execution. > > I'm using: > valgrind --tool=memcheck --leak-check=full --leak-resolution=high > --trace-children=yes --show-reachable=yes <command line> > > It works brillantly, and display lines like: > > 2048 bytes in 1 blocks are definately lost in loss record 6 of 6 > at 0x1B90088D: malloc (vg_replace_malloc.c:149) > by 0x1b9C4e6d: ???? > by ... > > Is there a way to tell what address the block is at ? In my program, > the address used will malloc many, many times, with the memory following > different paths - by knowing the address, I can figure out where it > is going using printfs. I don't think so. Memcheck doesn't record the block addresses, because each message can describe many blocks, as in this case: > 2048 bytes in 32 blocks are definately lost in loss record 6 of 6 It commons up all the info about the 32 blocks into a single lump, losing the individual block addresses as it does. You'd have to hack around memcheck/mac_leakcheck.c a bit. 'lc_shadows' is the array holding all the remaining heap blocks. The call to 'VG_(unique_error)()' is where each loss record is recorded; you could at that point scan through 'lc_shadows' and print out some info about every MAC_Chunk in 'lc_shadows' that matched the loss record. Nick |