|
From: Julian S. <js...@ac...> - 2005-02-24 10:32:03
|
[My ISP seems to have lost the last 24 hours of inbound mail. So am constructing a reply from the list archive at SF.] > What do people think? Overall, it sounds like a good thing. I have some questions tho (in no particular order) > * It under-reports lost memory, by only pointing out completely > undereferenced allocations. This means that apparently small > leaks are actually large, if they refer to a lot of other > memory. > * It completely fails to report leaked cycles. We have software > which uses refcounting, which also loses cycles; we were hoping > that Valgrind would point out deficiencies in the refcount management. > * It doesn"t trace from registers, so it can report blocks as leaked > even if there"s a register reference (not common, I admit). > > To fix all this, I changed the leak checker to use a standard mark-sweep > algorithm. It does a pass from the root set to find unleaked memory, > and then makes a pass over the leaked memory to group it into cliques > (connected graph of allocations); each clique is reported as a leak, > rather than each individual allocation. The real problem is not to implement algorithm X, Y or Z. It is to explain to users what it is that V is really measuring for them - build them a useful mental model of what's happening - so they can reason about what's going on. The existing scheme is at least simple, in that you can simply say that a block is leaked/potentially leaked if no pointer to it is found/only a pointer to its interior is found. And from the kind of questions that have arisen in the past, it already confuses users. Once you get into cycle detection, we need to explain about root sets and chasing pointers from there. Could you circulate a proposed documentation update? ---------- Other comments. * Clique is the wrong terminology. My understanding is that a clique is a completely-connected set of nodes in an undirected graph: each node-pair in the clique has a connecting edge. What you mean is Strongly Connected Components (SCCs), which are always associated with finding cycles in directed graphs. * How much extra storage will the SCC detector require in the worst case? > >On some architectures (e.g. Mac OS X on PowerPC) you need to > >scan registers other than the general-purpose ones. If you catch > >optimized, unrolled memmove() at the wrong point, a floating-point > >or vector register could contain the only extant copy of a pointer > >value. You'd have to be pretty unlucky to hit this while using > >Valgrind's leak check, so it may not be worth worrying about. > > > > > Sounds a bit unlikely. It would be tricky because you'd have to chop > the vector up into pointer-sized chunks and inspect each of them. Jeremy is right in that we should also chase roots from registers. The discussion about which regs do and don't contain pointers is spurious, when viewed in a wider context: we are prepared to consider any aligned, accessible, defined word in memory as a potential pointer with no further questions asked. So why make a distinction for register-held values? In short, chase from all register sources, including vector registers. Note that advanced compilers (icc et al) generate vector loops for all kinds of code and you can't assume that vector registers won't contain the-only-copies-of-pointers-in-transit at some point. Chopping up registers etc is not a big deal. Valgrind already does not know the layout of guest-state (in Vex-world) and has to ask Vex even basic questions (where/how big is the PC? SP? etc). So it's not much of a leap to ask Vex to enumerate all the word-sized guest- state offsets pertaining to int/vector registers. J |