This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [patch][google/integration] Add lightweight checks to vector::begin et. al. (issue4973065)
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.
Chris