Google has implemented a series of patches which allows us to catch many STL mis-use bugs cheaply and in ABI-compatible way: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01186.html http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01074.html and more ... (just look for __google_stl in google/integration branch). Some of the bugs we catch this way are not visible to "standard" tools like Valgrind and AddressSanitizer. These bugs (and more) *are* visible to _GLIBCXX_DEBUG mode, but we've not been able to use that mode due to source incompatibilities, and it has ABI implications as well. Please consider adding a light-weight ABI-compatible debug mode to trunk, once it re-opens for stage 1.
Confirmed. c.f. https://gcc.gnu.org/ml/libstdc++/2014-06/msg00105.html
As of r227595 trunk now supports a _GLIBCXX_ASSERTIONS macro that enables lightweight checks. We will start merging some of the __google_stl checks to trunk and enabling them with that macro (which might give you a number of merge conflicts on your branch, sorry!)
The __google_stl_* checks were added by these commits ... Strict weak ordering checks in algos and RB trees: 8cc511b5e5c0814584644c90cb0d65d27182eddd Invariant checks and range checks in vector<bool>: ceeb7c3b17883b21f523ab0bef937f654b12eceb Range checks in deque: 0681de38f1f402ad5f1fd9cf9959f304c36f7c10 Non-empty checks in vector: 2b4e2a67ff643ebdc4dababd95010699918ad9e0 Dead stores in vector dtor: e1a3b2e088d16544b6b64e483e12ae77a813a274 Invariant checks in vector: 7a058129926f4838bc1344f3674c1a35052a03e4 Range checks in vector and vstring, scribbling in cleared vstring: 13480920300b3cf5f09d408fe249c873fbef1ee0 All the range checks and non-empty checks should be already enabled by _GLIBCXX_ASSERTIONS. The invariant checking and strict weak order checks may be too expensive to add to _GLIBCXX_ASSERTIONS. We could consider adding the dead stores in the destructors to wipe out the memory, so that subsequent accesses fail fast. Those stores should be optimised away so will have no cost in optimised builds, but might help in -O0 builds when debugging.
(In reply to Jonathan Wakely from comment #3) > The __google_stl_* checks were added by these commits ... > > Strict weak ordering checks in algos and RB trees: > 8cc511b5e5c0814584644c90cb0d65d27182eddd > > Invariant checks and range checks in vector<bool>: > ceeb7c3b17883b21f523ab0bef937f654b12eceb > > Range checks in deque: 0681de38f1f402ad5f1fd9cf9959f304c36f7c10 > > Non-empty checks in vector: 2b4e2a67ff643ebdc4dababd95010699918ad9e0 > Dead stores in vector dtor: e1a3b2e088d16544b6b64e483e12ae77a813a274 > Invariant checks in vector: 7a058129926f4838bc1344f3674c1a35052a03e4 > Range checks in vector and vstring, scribbling in cleared vstring: > 13480920300b3cf5f09d408fe249c873fbef1ee0 > > All the range checks and non-empty checks should be already enabled by > _GLIBCXX_ASSERTIONS. > > The invariant checking and strict weak order checks may be too expensive to > add to _GLIBCXX_ASSERTIONS. But see PR 86843. > We could consider adding the dead stores in the destructors to wipe out the > memory, so that subsequent accesses fail fast. Those stores should be > optimised away so will have no cost in optimised builds, but might help in > -O0 builds when debugging. That's PR 56103. So is there any reason to keep this PR open? Are there still checks we should copy from the google branch?
Already covered by PR 86843 and PR 56103.
Thanks, Paul.