Build failure: arrow-cpp on darwin+staging-next

[nekowinston]

Nixpkgs version

• staging-next (81ed1c7)

Steps to reproduce

Try to build arrow-cpp on staging-next on a darwin system (#457894 (comment))

Can Hydra reproduce this build failure?

Yes, Hydra can reproduce this build failure.

Link to Hydra build job

https://hydra.nixos.org/build/312785283

Relevant log output

77/94 Test #77: arrow-flight-internals-test ..................***Failed    3.64 sec
Running arrow-flight-internals-test, redirecting output into /private/tmp/nix-build-arrow-cpp-20.0.0.drv-0/source/cpp/build/build/test-logs/arrow-flight-internals-test.txt (attempt 1/1)
/private/tmp/nix-build-arrow-cpp-20.0.0.drv-0/source/cpp/build-support/run-test.sh: line 88: 63682 Abort trap: 6              $TEST_EXECUTABLE "$@" > $LOGFILE.raw 2>&1
/private/tmp/nix-build-arrow-cpp-20.0.0.drv-0/source/cpp/build/src/arrow/flight

78/94 Test #78: arrow-flight-sql-test ........................***Failed    2.22 sec
Running arrow-flight-sql-test, redirecting output into /private/tmp/nix-build-arrow-cpp-20.0.0.drv-0/source/cpp/build/build/test-logs/arrow-flight-sql-test.txt (attempt 1/1)
/private/tmp/nix-build-arrow-cpp-20.0.0.drv-0/source/cpp/build-support/run-test.sh: line 88: 63717 Abort trap: 6              $TEST_EXECUTABLE "$@" > $LOGFILE.raw 2>&1
/private/tmp/nix-build-arrow-cpp-20.0.0.drv-0/source/cpp/build/src/arrow/flight/sql

Additional context

Creating an issue so I don't ping all the other people involved with staging-next, apologies if that's not the intended workflow for staging-next.

I compiled a debug build (with -fsanitize=address) and ran a manual ./debug/arrow-flight-internals-test, here's the output of that:

./debug/arrow-flight-internals-test
=================================================================
==75213==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x000103d3ade0 in thread T0
    #0 0x000107e45d04 in _ZdlPv+0x6c (libclang_rt.asan_osx_dynamic.dylib:arm64+0x6dd04)
    #1 0x00010500960c in google::protobuf::FileOptions::SharedDtor(google::protobuf::MessageLite&)+0x94 (libprotobuf.33.0.0.dylib:arm64+0xad60c)
    #2 0x000104ffd824 in google::protobuf::FileDescriptorProto::SharedDtor(google::protobuf::MessageLite&)+0x40 (libprotobuf.33.0.0.dylib:arm64+0xa1824)
    #3 0x000104ffd8a4 in google::protobuf::FileDescriptorProto::~FileDescriptorProto()+0x10 (libprotobuf.33.0.0.dylib:arm64+0xa18a4)
    #4 0x00010501b18c in google::protobuf::EncodedDescriptorDatabase::Add(void const*, int)+0x6c (libprotobuf.33.0.0.dylib:arm64+0xbf18c)
    #5 0x000104fad08c in google::protobuf::DescriptorPool::InternalAddGeneratedFile(void const*, int)+0x64 (libprotobuf.33.0.0.dylib:arm64+0x5108c)
    #6 0x00010506e6a0 in google::protobuf::internal::AddDescriptors(google::protobuf::internal::DescriptorTable const*)+0x90 (libprotobuf.33.0.0.dylib:arm64+0x1126a0)
    #7 0x0001840bacac in invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const+0x1b8 (dyld:arm64+0x20cac)
    #8 0x0001840f872c in invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const+0x140 (dyld:arm64+0x5e72c)
    #9 0x00018411753c in invocation function for block in mach_o::Header::forEachSection(void (mach_o::Header::SectionInfo const&, bool&) block_pointer) const+0x134 (dyld:arm64+0x7d53c)
    #10 0x000184114160 in mach_o::Header::forEachLoadCommand(void (load_command const*, bool&) block_pointer) const+0xcc (dyld:arm64+0x7a160)
    #11 0x0001841159f8 in mach_o::Header::forEachSection(void (mach_o::Header::SectionInfo const&, bool&) block_pointer) const+0x78 (dyld:arm64+0x7b9f8)
    #12 0x0001840f821c in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const+0x200 (dyld:arm64+0x5e21c)
    #13 0x0001840baa64 in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const+0xa8 (dyld:arm64+0x20a64)
    #14 0x0001840c28ac in dyld4::JustInTimeLoader::runInitializers(dyld4::RuntimeState&) const+0x20 (dyld:arm64+0x288ac)
    #15 0x0001840bb210 in dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&, dyld3::Array<dyld4::Loader const*>&) const+0x130 (dyld:arm64+0x21210)
    #16 0x0001840bb1b0 in dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&, dyld3::Array<dyld4::Loader const*>&) const+0xd0 (dyld:arm64+0x211b0)
    #17 0x0001840bb1b0 in dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&, dyld3::Array<dyld4::Loader const*>&) const+0xd0 (dyld:arm64+0x211b0)
    #18 0x0001840bb1b0 in dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&, dyld3::Array<dyld4::Loader const*>&) const+0xd0 (dyld:arm64+0x211b0)
    #19 0x0001840bb1b0 in dyld4::Loader::runInitializersBottomUp(dyld4::RuntimeState&, dyld3::Array<dyld4::Loader const*>&, dyld3::Array<dyld4::Loader const*>&) const+0xd0 (dyld:arm64+0x211b0)
    #20 0x0001840bfe4c in dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const::$_0::operator()() const+0xb0 (dyld:arm64+0x25e4c)
    #21 0x0001840bb52c in dyld4::Loader::runInitializersBottomUpPlusUpwardLinks(dyld4::RuntimeState&) const+0x2c8 (dyld:arm64+0x2152c)
    #22 0x0001840dd048 in dyld4::APIs::runAllInitializersForMain()+0x18c (dyld:arm64+0x43048)
    #23 0x00018409f154 in dyld4::prepare(dyld4::APIs&, mach_o::Header const*)+0xc24 (dyld:arm64+0x5154)
    #24 0x00018409dd00 in start+0x1bbc (dyld:arm64+0x3d00)

Address 0x000103d3ade0 is a wild pointer inside of access range of size 0x000000000001.
SUMMARY: AddressSanitizer: bad-free (libprotobuf.33.0.0.dylib:arm64+0xad60c) in google::protobuf::FileOptions::SharedDtor(google::protobuf::MessageLite&)+0x94
==75213==ABORTING
[1]    75213 abort      ./debug/arrow-flight-internals-test

This lead me to protocolbuffers/protobuf#5290; to find out which dynamic libararies the binary links to, I ran it with DYLD_PRINT_LIBRARIES=1, here is the output for that for both current nixpkgs@master and nixpkgs@staging-next: https://gist.github.com/nekowinston/f6cbea976ba4605f318b9329d96a0544.

To fix the tests, I tried grpc.override { protobuf = protobuf_31; }, to prevent protobuf_33 ending up in the derivation, this built & passed tests successfully. I also tried adding strictDeps to grpc itself, but this didn't help. Not exactly sure what's going in here, but wanted to ping the maintainers with the info I gathered; let me know if there's anything else I can help with.

System metadata

• system: "aarch64-darwin"
• host os: Darwin 25.0.0, macOS 26.0.1
• multi-user?: yes
• sandbox: no
• version: nix-env (Determinate Nix 3.12.0) 2.32.1
• nixpkgs: /nix/store/zrfsqn9i68kwvb6idjdfk5nhdbdcf6xk-source

Notify maintainers

@tobim @veprbl @cpcloud

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[vcunat]

For now I skipped the tests in a4402b2, but sure, keep looking for a real fix.