# Steps to reproduce (in terms of terminal commands) $ cat test2.cpp #include <set> #include <cstdio> int main() { std::set<int> s{}; printf("%i\n", *s.begin()); } $ g++ test2.cpp -o a -g3 -O0 -fsanitize=address,undefined $ ./a ## Expected It either crashes on past-end access, or produces a warning (depending on whether it's handled as a past-end access or UB). ## Actual It prints: 0
Btw, worth noting that clang 8.0.1 does not handle it either.
Confirmed, we're slowly adding instrumentation for std containers to sanitizers.
-D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it detects this.
(In reply to Marc Glisse from comment #3) > -D_GLIBCXX_DEBUG is the current way to add many checks to libstdc++, and it > detects this. Oh, cool, I'll make use of it, thanks for the hint!
(In reply to Konstantin Kharlamov from comment #0) > It either crashes on past-end access, or produces a warning (depending on > whether it's handled as a past-end access or UB). No, that's not how undefined behaviour works. You are wrong to expect a crash, and not all cases of undefined behaviour can be detected reliably. I don't think this case can be caught by sanitizers. As Marc said (and as I suggested on your previous bug report) you should use -D_GLIBCXX_DEBUG to catch these kind of bugs.
(In reply to Jonathan Wakely from comment #5) > No, that's not how undefined behaviour works. You are wrong to expect a crash No, in context of the report I'm not. You're correct this is not how UB works, but this is how address sanitizer does. > and not all cases of undefined behaviour can be detected reliably. Well, given -D_GLIBCXX_DEBUG does handle it, probably sanitizer can either. > As Marc said (and as I suggested on your previous bug report) you should use > -D_GLIBCXX_DEBUG to catch these kind of bugs. Right, thanks, FTR: my prev. report was handled by sanitizer correctly, so back then I wouldn't need to use the additional debugging option.
@Jonathan Wakely I think you accidentally closed the report, would you mind to reopen it (I'm not seeing why would it be "invalid", people even confirmed that more support for std containers is being added to sanitizers).
(In reply to Konstantin Kharlamov from comment #6) > (In reply to Jonathan Wakely from comment #5) > > > No, that's not how undefined behaviour works. You are wrong to expect a crash > > No, in context of the report I'm not. You're correct this is not how UB > works, but this is how address sanitizer does. The past-the-end iterator of a std::set doesn't point to the heap, and points to a valid object that is always readable. I don't see how asan can help here. > > and not all cases of undefined behaviour can be detected reliably. > > Well, given -D_GLIBCXX_DEBUG does handle it, probably sanitizer can either. No, I don't agree. They work very differently. Closing the bug was not an accident, I don't believe there are any plans to add asan instrumentation to std::set, and I don't believe it's possible to handle the past-the-end case.
I'll call it WONTFIX rather than INVALID if you prefer, but it's not going to be handled by asan either way.