On Tue, Sep 6, 2011 at 12:44 PM, Jonathan Wakely <jwakely....@gmail.com> wrote: > On 6 September 2011 20:23, Jonathan Wakely wrote: >> >> What's a dangling vector anyway? One that has been moved from? > > Apparently not, since a moved-from vector would pass __valid() (as > indeed it should) > > So I'm quite curious what bugs this catches.
The garden variety "use after free": vector<> *v = new vector<>; ... delete v; ... for (it = v->begin(); it != v->end(); ++it) // Oops! > The existing debug mode > catches some fairly subtle cases of user error such as comparing > iterators from different containers, or dereferencing past-the-end > iterators. This patch seems to catch user errors related to ... what? > Heap corruption? Using a vector after its destructor runs? Those > are pretty serious, un-subtle errors and not specific to vector, so > why add code to vector (code which isn't 100% reliable if it only > catches corruption after the memory is reused and new data written to > it) It is 100% percent reliable for us, due to use of a debugging allocator which scribbles on all free()d memory. But yes, that's one more reason why this patch is not really good for upstream. > to detect more general problems that can happen to any type? We can't (easily) catch the general problem. This patch allows us to easily catch this particular instance of it. > The fact the patch did catch real bugs doesn't mean it's a good idea, > as you say, those bugs probably could have been caught in other ways. Sure -- we have other ways to catch the these bugs. They are not very practical at the moment due to their runtime overhead. As for your other suggestion: enabling _GLIBCXX_DEBUG just for vector, that didn't occur to me and is something I'd like to explore. Thanks, -- Paul Pluzhnikov
