|
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/ |