|
From: Michael R. <re...@gm...> - 2006-01-17 16:30:16
|
Hi I'm triying to find out the source of memleaks of a plugin I'm developing. The server has quite a few leaks (mostly during init). I don't care about most of them, so I would like to suppress them. But I'm a bit confused about the output of the leak checker. Studying the manuals and searching the archives didn't really enlighten me. I run the program via (The suppression options only when needed, of course): valgrind --tool=memcheck --suppressions=valgrind.supp --gen-suppressions=yes --leak-check=full --leak-resolution=high --show-reachable=no <program> <args> Valgrind nicly prints loss records for lost blocks. Like this: ==7085== 157,866 (40 direct, 157,826 indirect) bytes in 1 blocks are definitelylost in loss record 135 of 218 First of, do I understand "block" correctly as some amount of memory allocated at a time, and it doesn't say anything about the amount i.e. it can be 2byte, 57Kb or whatever? If so, how can 1 block be directly and indirectly leaked at the same time? Then I wonder which records are actually printed? Only 20something out those 218 are printed. So what about the rest? I suspected them to be either duplicates of the printed ones or still reachable blocks, but neither seems to be the case. They have different backtraces for instance. Also the numbers of blocks in the summary are way above the printed ones (counted together). So obviously the hidden ones add to the lost blocks in the summary as well. But why are they hidden then? I fear, actual leaks from my plugin might be hidden? When now generating suppressions, obviously I'm also asked for the not printed records. I get lots of: ==7100== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- but with no additional info. Which is not exactly much to base a decision on ;) Can I make valgrind a bit mor verbose? Some enlightenment would be great :) Greets Michael |
|
From: Tom H. <to...@co...> - 2006-01-17 16:56:25
|
In message <200...@gm...>
Michael Reiher <re...@gm...> wrote:
> I run the program via (The suppression options only when needed, of course):
>
> valgrind --tool=memcheck --suppressions=valgrind.supp --gen-suppressions=yes
> --leak-check=full --leak-resolution=high --show-reachable=no <program> <args>
>
> Valgrind nicly prints loss records for lost blocks. Like this:
>
> ==7085== 157,866 (40 direct, 157,826 indirect) bytes in 1 blocks are
> definitelylost in loss record 135 of 218
>
> First of, do I understand "block" correctly as some amount of memory allocated
> at a time, and it doesn't say anything about the amount i.e. it can be 2byte,
> 57Kb or whatever? If so, how can 1 block be directly and indirectly leaked at
> the same time?
The block count is the number of direct blocks lost I believe - so you
have one 40 byte block lost which contains pointers in one way or
another to another 157826 bytes of memory.
It doesn't report the number of indirect blocks lost.
> Then I wonder which records are actually printed? Only 20something out those
> 218 are printed. So what about the rest? I suspected them to be either
> duplicates of the printed ones or still reachable blocks, but neither seems
> to be the case. They have different backtraces for instance. Also the numbers
> of blocks in the summary are way above the printed ones (counted together).
> So obviously the hidden ones add to the lost blocks in the summary as well.
> But why are they hidden then? I fear, actual leaks from my plugin might be
> hidden?
Duplicates should already have been suppressed I think - that is done
as the loss records are computed.
> When now generating suppressions, obviously I'm also asked for the not printed
> records. I get lots of:
>
> ==7100== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ----
>
> but with no additional info. Which is not exactly much to base a decision
> on ;) Can I make valgrind a bit mor verbose?
Sounds like you have loss records for which it has failed to record
any location for some reason. Seems a bit odd.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2006-01-17 17:00:19
|
> In message <200...@gm...> > Michael Reiher <re...@gm...> wrote: > >> I run the program via (The suppression options only when needed, of >> course): >> >> valgrind --tool=memcheck --suppressions=valgrind.supp >> --gen-suppressions=yes >> --leak-check=full --leak-resolution=high --show-reachable=no <program> >> <args> >> >> Valgrind nicly prints loss records for lost blocks. Like this: >> >> ==7085== 157,866 (40 direct, 157,826 indirect) bytes in 1 blocks are >> definitelylost in loss record 135 of 218 >> >> First of, do I understand "block" correctly as some amount of memory >> allocated >> at a time, and it doesn't say anything about the amount i.e. it can be >> 2byte, >> 57Kb or whatever? If so, how can 1 block be directly and indirectly >> leaked at >> the same time? > > The block count is the number of direct blocks lost I believe - so you > have one 40 byte block lost which contains pointers in one way or > another to another 157826 bytes of memory. > > It doesn't report the number of indirect blocks lost. > >> Then I wonder which records are actually printed? Only 20something out >> those >> 218 are printed. So what about the rest? I suspected them to be either >> duplicates of the printed ones or still reachable blocks, but neither >> seems >> to be the case. They have different backtraces for instance. Also the >> numbers >> of blocks in the summary are way above the printed ones (counted >> together). >> So obviously the hidden ones add to the lost blocks in the summary as >> well. >> But why are they hidden then? I fear, actual leaks from my plugin might >> be >> hidden? > > Duplicates should already have been suppressed I think - that is done > as the loss records are computed. > >> When now generating suppressions, obviously I'm also asked for the not >> printed >> records. I get lots of: >> >> ==7100== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- >> >> but with no additional info. Which is not exactly much to base a >> decision >> on ;) Can I make valgrind a bit mor verbose? > > Sounds like you have loss records for which it has failed to record > any location for some reason. Seems a bit odd. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log > files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > |
|
From: Michael R. <mic...@gm...> - 2006-01-17 22:40:50
|
On Tuesday 17 January 2006 17:56, Tom Hughes wrote: > In message <200...@gm...> > > Michael Reiher <re...@gm...> wrote: > > I run the program via (The suppression options only when needed, of > > course): > > > > valgrind --tool=memcheck --suppressions=valgrind.supp > > --gen-suppressions=yes --leak-check=full --leak-resolution=high > > --show-reachable=no <program> <args> > > > > Valgrind nicly prints loss records for lost blocks. Like this: > > > > ==7085== 157,866 (40 direct, 157,826 indirect) bytes in 1 blocks are > > definitelylost in loss record 135 of 218 > > > > First of, do I understand "block" correctly as some amount of memory > > allocated at a time, and it doesn't say anything about the amount i.e. it > > can be 2byte, 57Kb or whatever? If so, how can 1 block be directly and > > indirectly leaked at the same time? > > The block count is the number of direct blocks lost I believe - so you > have one 40 byte block lost which contains pointers in one way or > another to another 157826 bytes of memory. > > It doesn't report the number of indirect blocks lost. > Ahh, I see, that makes sence... > > Then I wonder which records are actually printed? Only 20something out > > those 218 are printed. So what about the rest? I suspected them to be > > either duplicates of the printed ones or still reachable blocks, but > > neither seems to be the case. They have different backtraces for > > instance. Also the numbers of blocks in the summary are way above the > > printed ones (counted together). So obviously the hidden ones add to the > > lost blocks in the summary as well. But why are they hidden then? I fear, > > actual leaks from my plugin might be hidden? > > Duplicates should already have been suppressed I think - that is done > as the loss records are computed. > ... Then the reports apparently cover only the "definitly lost" blocks. And the hidden ones are probably the "indirectly lost" blocks? Is there a way to see information about those, too? > > When now generating suppressions, obviously I'm also asked for the not > > printed records. I get lots of: > > > > ==7100== ---- Print suppression ? --- [Return/N/n/Y/y/C/c] ---- > > > > but with no additional info. Which is not exactly much to base a decision > > on ;) Can I make valgrind a bit mor verbose? > > Sounds like you have loss records for which it has failed to record > any location for some reason. Seems a bit odd. > Don't think so. The backtraces seem ok when printing the suppressions for these cases. Greets Michael |