Last remaining lib from #179. The vcpkg move links but crashes at runtime, so it's deferred (flare stays on foreign jsoncpp 0.10.7).
What works
//thirdparty/jsoncpp thin wrapper over vcpkg#jsoncpp:jsoncpp (1.9.x), include_prefix={'jsoncpp':'json'} mapping flare's jsoncpp/<h> onto vcpkg's native json/<h>.- Links cleanly after three blade #1322 cmake-link fixes were needed (see below).
Blocker
Every flare gtest-based jsoncpp consumer SIGSEGVs at runtime — flare/base/option:json_parser_test, flare/rpc/protocol/protobuf:gdt_json_proto_conversion_test, and the http-builtin/binlog json tests — in the Json::Reader().parse() path. Deterministic.
Investigation (ruled out)
- Not a jsoncpp bug: a standalone program doing the same
Json::Reader().parse() on the same malformed input works (c++11 and c++20).
- Not the toolchain: flare and the vcpkg jsoncpp build both use Apple clang 17 + the Xcode 16.4 SDK (same libc++).
- Not
-std, -O2/NDEBUG, static-vs-shared linkage, the shared-libjson_parser.dylib structure, jsoncpp duplication, or symbol collisions — each reproduced in isolation; all pass.
- Localized to libc++
std::deque members of Json::Reader (constructed inline in flare's TU via Json::Reader(), mutated inside libjsoncpp).
- ASan with
detect_container_overflow=0 makes it pass -> a subtle memory/codegen-sensitive issue, not a logic bug.
- Reproducible only via the exact blade build; not in any hand-built equivalent.
Suspected: a subtle libc++ container ABI/codegen interaction in the blade build, or a misuse somewhere. Next steps: rebuild jsoncpp + its consumer closure entirely under ASan, or single-step the Json::Reader deque teardown in the blade-built binary.
Side work (kept for whoever picks this up)
Linking jsoncpp surfaced real blade #1322 gaps (a port whose CMake target name != its lib file, jsoncpp jsoncpp_lib/jsoncpp_static -> libjsoncpp.a). Fixes written + unit-tested but not yet landed (no other current consumer): exclude a port's own imported CMake targets; skip conditional *-namespaced-targets.cmake; let sibling-detection see shared libs (.dylib/.so).
Follow-up #192 (Reader/Writer -> CharReaderBuilder modernization) is orthogonal and may or may not sidestep this.
Last remaining lib from #179. The vcpkg move links but crashes at runtime, so it's deferred (flare stays on foreign jsoncpp 0.10.7).
What works
//thirdparty/jsoncppthin wrapper overvcpkg#jsoncpp:jsoncpp(1.9.x),include_prefix={'jsoncpp':'json'}mapping flare'sjsoncpp/<h>onto vcpkg's nativejson/<h>.Blocker
Every flare gtest-based jsoncpp consumer SIGSEGVs at runtime —
flare/base/option:json_parser_test,flare/rpc/protocol/protobuf:gdt_json_proto_conversion_test, and the http-builtin/binlog json tests — in theJson::Reader().parse()path. Deterministic.Investigation (ruled out)
Json::Reader().parse()on the same malformed input works (c++11 and c++20).-std,-O2/NDEBUG, static-vs-shared linkage, the shared-libjson_parser.dylibstructure, jsoncpp duplication, or symbol collisions — each reproduced in isolation; all pass.std::dequemembers ofJson::Reader(constructed inline in flare's TU viaJson::Reader(), mutated inside libjsoncpp).detect_container_overflow=0makes it pass -> a subtle memory/codegen-sensitive issue, not a logic bug.Suspected: a subtle libc++ container ABI/codegen interaction in the blade build, or a misuse somewhere. Next steps: rebuild jsoncpp + its consumer closure entirely under ASan, or single-step the
Json::Readerdeque teardown in the blade-built binary.Side work (kept for whoever picks this up)
Linking jsoncpp surfaced real blade #1322 gaps (a port whose CMake target name != its lib file, jsoncpp
jsoncpp_lib/jsoncpp_static->libjsoncpp.a). Fixes written + unit-tested but not yet landed (no other current consumer): exclude a port's own imported CMake targets; skip conditional*-namespaced-targets.cmake; let sibling-detection see shared libs (.dylib/.so).Follow-up #192 (Reader/Writer -> CharReaderBuilder modernization) is orthogonal and may or may not sidestep this.