Skip to content

Assert when using std::views::filter and GCC 10 #4440

Description

@gwjo

Description

After upgrading from 3.9.1 to 3.11.3 the code asserts when iterating over a json array that's been filtered using std::views::filter due to an uninitialized iterator.

In addition to my failure with 3.11.3 and GCC 10.2, I checked other combinations on Godbolt and observed the following (❌ represents the assert is seen)

GCC 10.2 GCC 10.5 GCC 11.1 GCC trunk Clang 16
3.9.1 ✅ ✅ ✅ ✅ ✅
3.10.5 ✅ ✅ ✅ ✅ ✅
3.11.1 ❌ ❌ ❌ ✅ ✅
trunk ❌ ❌ ❌ ✅ ✅

Reproduction steps

https://godbolt.org/z/WbexYTqnf

Expected vs. actual results

std::views::filter should allow you to filter a json array.

Minimal code example

#include <nlohmann/json.hpp>
#include <iostream>
#include <ranges>

using nlohmann::json;

int main()
{
    auto noOpFilter = std::views::filter([](auto&&){ return true; });
    json j = {1, 2, 3};
    auto filtered = j | noOpFilter;
    std::cout << *filtered.begin() << std::endl;
    return 0;
}

Error messages

output.s: /opt/compiler-explorer/libs/nlohmann_json/trunk/single_include/nlohmann/json.hpp:13346: bool nlohmann::json_abi_v3_11_3::detail::iter_impl<BasicJsonType>::operator==(const IterImpl&) const [with IterImpl = nlohmann::json_abi_v3_11_3::detail::iter_impl<nlohmann::json_abi_v3_11_3::basic_json<> >; typename std::enable_if<(std::is_same<IterImpl, nlohmann::json_abi_v3_11_3::detail::iter_impl<BasicJsonType> >::value || std::is_same<IterImpl, nlohmann::json_abi_v3_11_3::detail::iter_impl<typename std::conditional<std::is_const<_Tp>::value, typename std::remove_const<_Tp>::type, const BasicJsonType>::type> >::value), std::nullptr_t>::type <anonymous> = nullptr; BasicJsonType = nlohmann::json_abi_v3_11_3::basic_json<>]: Assertion `m_object != nullptr' failed.
Program terminated with signal: SIGSEGV

Compiler and operating system

GCC 10.2

Library version

3.11.3

Validation

Activity

  1. nlohmann commented on Nov 17, 2024

    @nlohmann
    Owner

    In #4498 I added the code above as test case. I get the same assertion error in the job for GCC 10.5. Furthermore, the test does not compiler with Clang 11. The test succeed with GCC 13.0 and Clang 19. Interestingly, there are no errors on Windows and macOS.

    To summarize (see https://github.com/nlohmann/json/actions/runs/11878152025):

    Does not work:

    • GCC 10.5.0 (assertion)
    • Clang 11.1.0 (compilation error)
    • Clang 12.0.1 (compilation error)
    • Clang 13.0.1 (compilation error)
    • Clang 14.0.6 (compilation error)
    • Clang 15.0.7 (compilation error)

    Works:

    • GCC 11.5.0
    • GCC 12.4.0
    • GCC 13.3.0
    • GCC 14.2.0
    • Clang 16.0.6
    • Clang 17.0.6
    • Clang 18.1.8
    • Clang 19.1.4

    Test skipped:

    • GCC 9.5.0
  2. nlohmann commented on Nov 18, 2024

    @nlohmann
    Owner

    So the feature works as expected with reasonably modern versions of GCC and Clang. The assertion in GCC 10.5.0 feels to me like a shortcoming of the implementation of std::views::filter. Maybe there is some documentation about the implementation status of ranges in GCC that can confirm this.

    For Clang, we see the features works as expected starting with Clang 16. The previous versions in the CI fail to compile the code. However, these tests rely on libstdc++ instead of libc++. Once I have some time, I will try to use libc++ with these compilers to check the behavior.

    If there is nothing in the library to fix this, then we can use Hedley to detect non-compliant compilers to exclude the test case and add a section to the documentation/README about ranges support.

    Any thoughts on this?

  3. github-actions commented on Feb 17, 2025

    @github-actions

    This issue has been marked as stale because it has been open for 90 days without activity. If this issue is still relevant, please add a comment or remove the "stale" label. Otherwise, it will be closed in 10 days. Thank you for helping us prioritize our work!

  4. added
    state: stalethe issue has not been updated in a while and will be closed automatically soon unless it is updated
    on Feb 17, 2025
  5. github-actions commented on Feb 28, 2025

    @github-actions

    This issue has been closed after being marked as stale for 10 days without any further activity. If this was done in error or the issue is still relevant, please feel free to reopen it or create a new issue. We appreciate your understanding and contributions.

  6. 4 remaining items

  7. added
    solution: proposed fixa fix for the issue has been proposed and waits for confirmation
    and removed
    state: please discussplease discuss the issue or vote for your favorite option
    state: stalethe issue has not been updated in a while and will be closed automatically soon unless it is updated
    on Jun 30, 2026
  8. added this to the Release 3.12.1 milestone on Jun 30, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions