Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiling with _GLIBCXX_DEBUG yields iterator-comparison warnings during tests #492

Closed
mikecrowe opened this issue Mar 9, 2017 · 6 comments

Comments

@mikecrowe
Copy link

mikecrowe commented Mar 9, 2017

I've been suffering from some strange problems when compiling with GCC6 and -Og. So, I tried adding:

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -D_GLIBCXX_DEBUG")

to CMakeLists.txt with v2.1.0 in order to enable libstdc++ debugging.

When I do this and run "make test" I get various errors about iterator comparisons (note that this was using my host compiler so it's actually GCC4.9):

e.g.:


/usr/include/c++/4.9/debug/safe_iterator.h:506:error: attempt to compare a
past-the-end iterator to a singular iterator.

Objects involved in the operation:
iterator "lhs" @ 0x0x7fff811b8670 {
type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPN8nlohmann10basic_jsonINSt7__debug3mapENS5_6vectorESsblmdSaNS3_14adl_serializerEEENSt9__cxx19986vectorIS9_SaIS9_EEEEENS7_IS9_SD_EEEE (mutable
iterator);
state = past-the-end;
references sequence with type 'NSt7__debug6vectorIN8nlohmann10basic_jsonINS_3mapES0_SsblmdSaNS1_14adl_serializerEEESaIS5_EEE' @ 0x0x234a4f0
}
iterator "rhs" @ 0x0x7fff811b8600 {
type = N11__gnu_debug14_Safe_iteratorIN9__gnu_cxx17__normal_iteratorIPN8nlohmann10basic_jsonINSt7__debug3mapENS5_6vectorESsblmdSaNS3_14adl_serializerEEENSt9__cxx19986vectorIS9_SaIS9_EEEEENS7_IS9_SD_EEEE (mutable
iterator);
state = singular;
references sequence with type 'NSt7__debug6vectorIN8nlohmann10basic_jsonINS_3mapES0_SsblmdSaNS1_14adl_serializerEEESaIS5_EEE' @ 0x0x234a4f0
}`

@nlohmann
Copy link
Owner

nlohmann commented Mar 9, 2017

I can confirm your findings with GCC 7 (7.0.1 20170305 (experimental)) running make CXX=g++ CXXFLAGS="-Og -D_GLIBCXX_DEBUG" check. I'm not sure what to make of this yet, but if it's a bug in the library, it needs to be fixed.

@nlohmann
Copy link
Owner

nlohmann commented Mar 9, 2017

The culprit is the following test:

SECTION("insert nothing (count = 0)")
{
    auto pos = j_array.end();
    auto it = j_array.insert(j_array.end(), 0, 5);
    CHECK(j_array.size() == 4);
    CHECK(it == pos);
    CHECK(j_array == json({1, 2, 3, 4}));
}

I wanted to check that the return value of the insert is one element before the end iterator. Hence, I saved the end iterator before insertion... And totally missed that the insertion may invalidate all iterators in case the size grew past the capacity. Hence, CHECK(it == pos); accesses the invalidated iterator pos. I need to reformulate the test case. The library itself is unaffected.

@nlohmann
Copy link
Owner

nlohmann commented Mar 9, 2017

This is the fix:

auto it = j_array.insert(j_array.end(), 0, 5);
CHECK(j_array.size() == 4);
// the returned iterator points to the first inserted element;
// there were 4 elements, so it should point to the 5th
CHECK(it == j_array.begin() + 4);
CHECK(j_array == json({1, 2, 3, 4}));

With it, all tests compile and execute without error with make CXX=g++ CXXFLAGS="-Og -D_GLIBCXX_DEBUG" check.

nlohmann added a commit that referenced this issue Mar 9, 2017
The original test case relied on an invalidated iterator. This error
did not occur before, but only with GCC with -D_GLIBCXX_DEBUG. This
commit fixes the test case. The library is unaffected by this change.
@nlohmann nlohmann self-assigned this Mar 9, 2017
@nlohmann nlohmann added this to the Release 3.0.0 milestone Mar 9, 2017
@nlohmann
Copy link
Owner

nlohmann commented Mar 9, 2017

@mikecrowe Can you check whether commit 758c4ad fixed the issue for you?

@mikecrowe
Copy link
Author

@mikecrowe Can you check whether commit 758c4ad fixed the issue for you?

The iterator failures are no longer occurring for me.

(I do see other failures that appear to be due to locale stuff. These happen with both GCC4.9 (Debian Jessie) and GCC6.3 (Debian Stretch.) I can create a separate issue for them if you aren't already aware of them.)

Thanks!

@nlohmann
Copy link
Owner

Thanks, so I can close this issue. No I am not aware of other problems, so I would be happy if you could add a new issue for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants