Fix allocation failure during JSON destruction

[michaelsam94]

This PR fixes #5135 by preventing allocation failures from the temporary destruction stack from escaping basic_json's noexcept destructor.

The existing iterative destruction path is kept unchanged for the normal case. It is now wrapped with the library's JSON_TRY / JSON_CATCH macros; if growing the heap-allocated stack throws, destruction falls back to the regular array/object cleanup below instead of allowing the exception to cross the destructor boundary and call std::terminate.

A regression test in unit-regression2.cpp injects a one-shot global allocation failure while destroying a structured JSON value, verifying that the destructor consumes the failing stack allocation path and returns normally.

• The changes are described in detail, both the what and why.
• If applicable, an existing issue is referenced.
• The Code coverage remained at 100%. A test case for every new line of code.
• If applicable, the documentation is updated.
• The source code is amalgamated by running make amalgamate.

Local verification:

/usr/bin/c++ -std=c++11 -Iinclude -Itests/src -Itests/thirdparty/doctest tests/src/unit.cpp tests/src/unit-regression2.cpp -o build-local/unit-regression2 && ./build-local/unit-regression2 --test-case='*5135*'
./build-local/unit-regression2
/usr/bin/c++ -std=c++11 -Iinclude -Itests/src -Itests/thirdparty/doctest tests/src/unit.cpp tests/src/unit-allocator.cpp -o build-local/unit-allocator && ./build-local/unit-allocator
printf '#include <nlohmann/json.hpp>\nint main(){ nlohmann::json j = nlohmann::json::array({1,2,3}); return j.size() == 3 ? 0 : 1; }\n' | /usr/bin/c++ -std=c++11 -Isingle_include -x c++ - -o build-local/single-smoke && ./build-local/single-smoke
printf '#include <nlohmann/json.hpp>\nint main(){ nlohmann::json j = nlohmann::json::array({1,2,3}); return j.size() == 3 ? 0 : 1; }\n' | /usr/bin/c++ -std=c++11 -fno-exceptions -DJSON_NOEXCEPTION -Iinclude -x c++ - -o build-local/noexceptions-smoke && ./build-local/noexceptions-smoke
git diff --check

I could not run the full CMake suite locally because cmake is not available on this machine's PATH.

[nlohmann]

I just merged a test which caused a conflict. Sorry, please rebase.

[michaelsam94]

Rebased onto current develop (acf076a) and resolved the test conflict by keeping the newly merged #4320 regression and placing the #5135 regression after it.\n\nRe-ran local checks:\n\n- unit-regression2: 9 test cases, 128 assertions passed\n- unit-allocator: 3 test cases, 17 assertions passed\n- single-header smoke compile\n- no-exceptions smoke compile\n- git diff --check

[github-actions]

This pull request has been marked as stale because it has had no activity for 30 days. While we won’t close it automatically, we encourage you to update or comment if it is still relevant. Keeping pull requests active and up-to-date helps us review and merge changes more efficiently. Thank you for your contributions!

[nlohmann]

Thanks for the fix — the JSON_TRY/JSON_CATCH wrapper does address the crash from #5135 in the common case. A review turned up a few things worth a look before merging:

Correctness

1. New dangling-pointer risk in external_constructor<>::construct() (to_json.hpp, e.g. external_constructor<value_t::string>::construct). Every overload does destroy(old_type); m_type = new_type; m_value = new_value;. Before this PR, if destroy() threw (OOM), execution never reached the m_type reassignment, so j stayed consistent (leaked, but not corrupted). Now destroy() never throws, so m_type is always updated — and if the second allocation (for the new value) then also fails under the same sustained memory pressure, j ends up with m_type and m_value referring to different types, i.e. a dangling pointer. Reproduction sketch: j holds a large/deeply-nested array, then j = someString; under persistent OOM — destroy() swallows the failure and frees the old array, m_type becomes string, then the string allocation also fails, leaving m_value.string pointing at freed memory while m_type == string.

2. Fix is a no-op under JSON_NOEXCEPTION alone. JSON_TRY/JSON_CATCH only expand to real try/catch when exceptions are compiler-enabled and JSON_NOEXCEPTION is undefined; otherwise they expand to if(true)/if(false). A build with -DJSON_NOEXCEPTION but without -fno-exceptions (a supported, documented combination) still gets a genuine std::bad_alloc from std::vector, but the new catch compiles away — so it still escapes the noexcept destructor and calls std::terminate(), reproducing basic_json destructor allocates memory, violating noexcept semantics #5135 exactly in that configuration. The new regression test is itself guarded with !defined(JSON_NOEXCEPTION), so this gap isn't covered.

3. JSON_CATCH(...) swallows more than allocation failures. It's a blanket catch, so a custom AllocatorType that throws something other than std::bad_alloc gets silently discarded and funneled into the same fallback path, even though the comment describes only the "heap-allocated stack cannot grow" case.

Design tradeoff worth a second look

4. The fallback (swallow, then let the container's normal allocator-based destroy run) falls through to ordinary recursive destruction for whatever wasn't flattened yet. Since every nested level's destroy() independently hits the same catch, under a sustained (not just transient) low-memory condition, each level fails its own flatten attempt too — so potentially the entire remaining tree ends up destroyed via plain recursion, which is exactly the stack-overflow-prone pattern the iterative flatten-to-heap-stack algorithm was originally introduced to avoid, and it kicks in specifically under memory pressure. Might be worth a comment (or a depth-based test) documenting that this residual risk was considered and accepted.

Minor

• The new regression test only injects a single one-shot failure on a 2–3 level deep structure, so it doesn't exercise any of the scenarios above.
• tests/src/unit-regression2.cpp: the global operator new/delete override is active for the whole unit-regression2 binary rather than scoped to just the new TEST_CASE.
• const bool allocation_failure_was_injected = !fail_next_global_allocation; ... CHECK(allocation_failure_was_injected); could just be CHECK_FALSE(fail_next_global_allocation);.

(Comment drafted with the help of Claude Code.)

[nlohmann]

Fix conflicts and check out #5239 (comment)