|
From: Tom H. <to...@co...> - 2009-09-04 16:09:08
|
There appears to be a regression in the leak checker in 3.5.0 such that
things are falsely being reported as possibly leaked. Here is the leak
checker summary from 3.4.1 on a program:
==30145== LEAK SUMMARY:
==30145== definitely lost: 0 bytes in 0 blocks.
==30145== possibly lost: 0 bytes in 0 blocks.
==30145== still reachable: 191,081 bytes in 175 blocks.
==30145== suppressed: 0 bytes in 0 blocks.
and here is what 3.5.0 says about exactly the same program:
==11969== LEAK SUMMARY:
==11969== definitely lost: 0 bytes in 0 blocks
==11969== indirectly lost: 0 bytes in 0 blocks
==11969== possibly lost: 56,534 bytes in 86 blocks
==11969== still reachable: 134,547 bytes in 89 blocks
==11969== suppressed: 0 bytes in 0 blocks
the byte and block counts add up so it is still finding the same amount
of memory in total, just classifying it differently.
I don't have a simple test case, but by adding some extra debug code to
both valgrind and the program being checked I have worked out what is
happening to cause one particular block to be marked as possibly lost.
The scenario is that we have a list of blocks with the initial pointer
in a static variable. The blocks are chained together via pointer to the
start of each block, and in addition each block has a pointer to the
start of another block as shown here:
R --> B1 --> B2 --> B3 --> ...
| | |
| | |
V V V
I1 I2 I3
If that was all we had then everything would be fine. Unfortunately in
addition to what it shown above, there is also a second pointer to each
block in the list which does not point to the start of the block. Those
pointers are themselves held in valid, reachable memory.
The sequence of events I am seeing for a block in the list (B2 for
example) when the leak check runs is:
- Interior pointer to B2 found, B2 changed to Possible.
- B2 scanned and pointer to I2 found. I2 marked as Possible
because B2 is only Possible.
- Start pointer to B2 found and B2 upgraded to Reachable.
Which is where we finish, with B2 Reachable but I2 only Possible...
Any suggestions on a fix?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2009-09-04 16:31:43
|
On Friday 04 September 2009, Tom Hughes wrote: > There appears to be a regression in the leak checker in 3.5.0 [...] Nick looked in great detail at, and overhauled, the leak checker a couple of months back. It may be that this change of categorisation is deliberate. Anyway, let's see what he says. J |
|
From: Nicholas N. <n.n...@gm...> - 2009-09-04 22:02:32
|
On Sat, Sep 5, 2009 at 2:08 AM, Tom Hughes<to...@co...> wrote: > > R --> B1 --> B2 --> B3 --> ... > | | | > | | | > V V V > I1 I2 I3 > > The sequence of events I am seeing for a block in the list (B2 for > example) when the leak check runs is: > > - Interior pointer to B2 found, B2 changed to Possible. > > - B2 scanned and pointer to I2 found. I2 marked as Possible > because B2 is only Possible. > > - Start pointer to B2 found and B2 upgraded to Reachable. > > Which is where we finish, with B2 Reachable but I2 only Possible... Hmm, I can believe that. I don't think I considered the was-Possible-now-Reachable-so-recategorise-children case. If the old code got it right I suspect it was as much luck as anything else. > Any suggestions on a fix? Two possibilities off the top of my head: - When a block is upgraded from Possible to Reachable, rescan children. - Reconsider the categorisations. Ie. in case 7 in this part of the documentation: http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks should BBB be considered "Possibly Lost" or something else? Can you file a bug report and assign it to me? And mark it as a 3.5.1 blocker? (Nb: you can only mark something as a blocker after you've filed it.) N |
|
From: Tom H. <to...@co...> - 2009-09-07 07:57:43
Attachments:
leaktest.c
|
On 04/09/09 23:02, Nicholas Nethercote wrote: > On Sat, Sep 5, 2009 at 2:08 AM, Tom Hughes<to...@co...> wrote: >> >> R --> B1 --> B2 --> B3 --> ... >> | | | >> | | | >> V V V >> I1 I2 I3 >> >> The sequence of events I am seeing for a block in the list (B2 for >> example) when the leak check runs is: >> >> - Interior pointer to B2 found, B2 changed to Possible. >> >> - B2 scanned and pointer to I2 found. I2 marked as Possible >> because B2 is only Possible. >> >> - Start pointer to B2 found and B2 upgraded to Reachable. >> >> Which is where we finish, with B2 Reachable but I2 only Possible... > > Hmm, I can believe that. I don't think I considered the > was-Possible-now-Reachable-so-recategorise-children case. Attached is a simple test case which I've constructed to demonstrate the problem. I'm playing around with some possible fixes now... Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2009-09-07 08:25:17
|
On 04/09/09 23:02, Nicholas Nethercote wrote: > On Sat, Sep 5, 2009 at 2:08 AM, Tom Hughes<to...@co...> wrote: >> >> R --> B1 --> B2 --> B3 --> ... >> | | | >> | | | >> V V V >> I1 I2 I3 >> >> The sequence of events I am seeing for a block in the list (B2 for >> example) when the leak check runs is: >> >> - Interior pointer to B2 found, B2 changed to Possible. >> >> - B2 scanned and pointer to I2 found. I2 marked as Possible >> because B2 is only Possible. >> >> - Start pointer to B2 found and B2 upgraded to Reachable. >> >> Which is where we finish, with B2 Reachable but I2 only Possible... > > Hmm, I can believe that. I don't think I considered the > was-Possible-now-Reachable-so-recategorise-children case. > > If the old code got it right I suspect it was as much luck as anything else. > >> Any suggestions on a fix? > > Two possibilities off the top of my head: > > - When a block is upgraded from Possible to Reachable, rescan children. This was what I had come up with as well, but I hadn't managed to get it to work on Friday. > - Reconsider the categorisations. Ie. in case 7 in this part of the > documentation: > > http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.leaks > > should BBB be considered "Possibly Lost" or something else? That looks fine to me actually. > Can you file a bug report and assign it to me? And mark it as a 3.5.1 > blocker? (Nb: you can only mark something as a blocker after you've > filed it.) Filed as #206600 with test case and patch attached. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |