Consider building with _LIBCPP_DEBUG in debug or sanitizer builds |
|
Issue description_LIBCPP_DEBUG enables checks that eg. make sure iterators that are compared belong to the same collection. It has two levels (-D_LIBCPP_DEBUG=1 and -D_LIBCPP_DEBUG=2) with the second enabling some more strict checks. We should consider setting this in debug builds or possibly ubsan builds or similar if it would make debug builds too slow.
,
Jan 18
(5 days ago)
The first level doesn't but the second does. Looks like the first level has a slowdown of ~15% and the second is much worse: I tried running base_unittests which normally takes 40s, but with the second level debug it's been going for over 20 minutes and there's no sign of it making further progress :P
,
Jan 18
(5 days ago)
That's probably worth an upstream bug report -- but also an indicator that nobody uses level 2 at least. We can try level 1 and see how well it works and what issues it catches. If it just finds stuff that the sanitizers already find, it's probably not worth it.
,
Jan 18
(4 days ago)
> That's probably worth an upstream bug report -- but also an indicator that nobody uses level 2 at least. Yep, definitely a bug. When using level 2, the first dozen tests or so finish quickly (test output says 0ms per test), but then makes no further progress. I see 48 procs that are all in the sleep state and are using 0% cpu. So I believe there's some sort of deadlock since level 2 enables many checks that rely on a database full of collections and iterators, and all reads/writes to it are serialized with a mutex. I'll try to find some time to debug this next week. |
|
►
Sign in to add a comment |
|
Comment 1 by thakis@google.com
, Jan 18 (5 days ago)