[patch][google/integration] Add lightweight checks to vector::begin et. al. (issue4973065)

Christopher Jefferson caj21@st-andrews.ac.uk
Tue Sep 6 20:34:00 GMT 2011

On 6 Sep 2011, at 21:19, Paul Pluzhnikov wrote:

> On Tue, Sep 6, 2011 at 12:44 PM, Jonathan Wakely <jwakely.gcc@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.

It might be interesting to profile your app under _GLIBCXX_DEBUG, and see where the high costs are.

I previously found that stable_sort had a stupidly high cost, and it turned out with some tweaking we could get just as much protection with a lower cost. 


More information about the Gcc-patches mailing list