GH-46508: [C++] Upgrade OpenTelemetry cpp to avoid build error on recent Clang

[zanmato1984]

Rationale for this change

A warning is introduced in Clang 19.1.0 and AppleClang 17.0.0 that won't be demoted by -Wno-error, causing opentelemetry-cpp build failure.

What changes are included in this PR?

Upgrade opentelemetry-cpp (and opentelemetry-proto correspondingly) to the most recent version, which has addressed this issue in open-telemetry/opentelemetry-cpp#3133.

With this upgrade, we found several false-positives in sanitizers. The reason seems to be that we build bundled third-party dependencies as static libraries and don't instrument their code. This is known to cause false-positives as per https://github.com/google/sanitizers/wiki/threadsanitizercppmanual#non-instrumented-code . So some suppressions and disablements are also made in this PR.

Are these changes tested?

Manually build pass.

Are there any user-facing changes?

None.

• GitHub Issue: [C++] Build error on Apple Clang 17.0.0 when using bundled OpenTelemetry #46508

[github-actions]

⚠️ GitHub issue #46508 has been automatically assigned in GitHub to PR creator.

[zanmato1984]

@github-actions crossbow submit -g cpp

[github-actions]

Revision: 39582b65c86e0f2b613b412d045b4078c90e837b

Submitted crossbow builds: ursacomputing/crossbow @ actions-0137efa559

Task	Status
example-cpp-minimal-build-static
example-cpp-minimal-build-static-system-dependency
example-cpp-tutorial
test-alpine-linux-cpp
test-build-cpp-fuzz
test-conda-cpp
test-conda-cpp-meson
test-conda-cpp-valgrind
test-cuda-cpp-ubuntu-22.04-cuda-11.7.1
test-debian-12-cpp-amd64
test-debian-12-cpp-i386
test-fedora-39-cpp
test-ubuntu-22.04-cpp
test-ubuntu-22.04-cpp-20
test-ubuntu-22.04-cpp-bundled
test-ubuntu-22.04-cpp-emscripten
test-ubuntu-22.04-cpp-no-threading
test-ubuntu-24.04-cpp
test-ubuntu-24.04-cpp-bundled-offline
test-ubuntu-24.04-cpp-gcc-13-bundled
test-ubuntu-24.04-cpp-gcc-14
test-ubuntu-24.04-cpp-minimal-with-formats
test-ubuntu-24.04-cpp-thread-sanitizer

[kou]

Do we still need this with the latest OpenTelemetry C++?

[zanmato1984]

No we don't, as long as we all agree with to upgrade.

Please see #46509 (comment)

[kou]

Ah, OK. We can upgrade bundled OpenTelemetry C++ if our CI passes with it. So let's remove this.

[zanmato1984]

Done. Also triggered a crossbow build. Let's see the result. Thanks.

[zanmato1984]

Seems that recent opentelemetry introduces sanitizer failures, e.g.: https://github.com/ursacomputing/crossbow/actions/runs/15148842343/job/42590903382 https://github.com/apache/arrow/actions/runs/15148814357/job/42590835285?pr=46509

@kou Shall we keep investigating these failures or fallback to the original fix? Thanks.

[zanmato1984]

For TSAN I'm not sure if this is the case. I did debug a bit today but still no clue. It's much more difficult than I expected. Plus we have new emerging ASAN errors after suppressing the leak error.

I'll keep looking but this will take quite some longer.

[kou]

For TSAN I'm not sure if this is the case. I did debug a bit today but still no clue. It's much more difficult than I expected.

How about asking OpenTelemetry C++ developers at https://github.com/open-telemetry/opentelemetry-cpp/discussions ?

Plus we have new emerging ASAN errors after suppressing the leak error.

https://github.com/apache/arrow/actions/runs/15152202496/job/42600231311?pr=46509#step:7:4072

==16624==ERROR: AddressSanitizer: heap-use-after-free on address 0x604000010a18 at pc 0x556f354d1d0f bp 0x7fff3cb44c80 sp 0x7fff3cb44c78
WRITE of size 4 at 0x604000010a18 thread T0
    #0 0x556f354d1d0e in __exchange_and_add /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/atomicity.h:66:12
    #1 0x556f354d1d0e in __exchange_and_add_dispatch /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/ext/atomicity.h:101:14
    #2 0x556f354d1d0e in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:165:6
    #3 0x556f354d197e in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count() /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:705:11
    #4 0x556f35500534 in std::__shared_ptr<opentelemetry::v1::trace::NoopTracer, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr() /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr_base.h:1154:31
    #5 0x556f354f84c0 in std::shared_ptr<opentelemetry::v1::trace::NoopTracer>::~shared_ptr() /usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/shared_ptr.h:122:11
    #6 0x7f9743791a55 in __cxa_finalize (/lib/x86_64-linux-gnu/libc.so.6+0x45a55) (BuildId: cd410b710f0f094c6832edd95931006d883af48e)
    #7 0x7f974f0a9ac6 in __do_global_dtors_aux crtstuff.c

It seems that this is also related to https://github.com/open-telemetry/opentelemetry-cpp/blob/v1.20.0/sdk/src/trace/tracer.cc#L41-L42 .
I think that we can suppress this too.

[zanmato1984]

I think that we can suppress this too.

@kou Do you happen to know how to suppress this one? I did some search but couldn't find en effective way to do it.

How about asking OpenTelemetry C++ developers at open-telemetry/opentelemetry-cpp/discussions ?

Yeah, I'll try to look into it for some more time. If it doesn't work out, I'll ask for help from opentelemetry community.

Thanks for the suggestion.

[kou]

Could you try the following?

Add suppressions option for ASAN:

diff --git a/cpp/build-support/run-test.sh b/cpp/build-support/run-test.sh
index 55e3fe0980..f176586a0f 100755
--- a/cpp/build-support/run-test.sh
+++ b/cpp/build-support/run-test.sh
@@ -75,10 +75,9 @@ function setup_sanitizers() {
   UBSAN_OPTIONS="$UBSAN_OPTIONS suppressions=$ROOT/build-support/ubsan-suppressions.txt"
   export UBSAN_OPTIONS
 
-  # Enable leak detection even under LLVM 3.4, where it was disabled by default.
-  # This flag only takes effect when running an ASAN build.
-  # ASAN_OPTIONS="$ASAN_OPTIONS detect_leaks=1"
-  # export ASAN_OPTIONS
+  # Set up suppressions for AddressSanitizer
+  ASAN_OPTIONS="$ASAN_OPTIONS suppressions=$ROOT/build-support/asan-suppressions.txt"
+  export ASAN_OPTIONS
 
   # Set up suppressions for LeakSanitizer
   LSAN_OPTIONS="$LSAN_OPTIONS suppressions=$ROOT/build-support/lsan-suppressions.txt"

Add cpp/build-support/asan-suppressions.txt:

type:opentelemetry::v1::trace::NoopTracer

See also: https://clang.llvm.org/docs/AddressSanitizer.html

[zanmato1984]

Thanks. ASAN suppressions added, let's see.

[zanmato1984]

@github-actions crossbow submit -g cpp

[github-actions]

Revision: ac164b5b6714093bae5833bfe93568b90ed86a9d

Submitted crossbow builds: ursacomputing/crossbow @ actions-90fb7c3af6

Task	Status
example-cpp-minimal-build-static
example-cpp-minimal-build-static-system-dependency
example-cpp-tutorial
test-alpine-linux-cpp
test-build-cpp-fuzz
test-conda-cpp
test-conda-cpp-meson
test-conda-cpp-valgrind
test-cuda-cpp-ubuntu-22.04-cuda-11.7.1
test-debian-12-cpp-amd64
test-debian-12-cpp-i386
test-fedora-39-cpp
test-ubuntu-22.04-cpp
test-ubuntu-22.04-cpp-20
test-ubuntu-22.04-cpp-bundled
test-ubuntu-22.04-cpp-emscripten
test-ubuntu-22.04-cpp-no-threading
test-ubuntu-24.04-cpp
test-ubuntu-24.04-cpp-bundled-offline
test-ubuntu-24.04-cpp-gcc-13-bundled
test-ubuntu-24.04-cpp-gcc-14
test-ubuntu-24.04-cpp-minimal-with-formats
test-ubuntu-24.04-cpp-thread-sanitizer

[zanmato1984]

CI is good. I'm merging it.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit 35b9a89.

There were 71 benchmark results with an error:

• Commit Run on arm64-t4g-2xlarge-linux at 2025-06-03 04:19:53Z
  • tpch (R) with engine=arrow, format=parquet, language=R, memory_map=False, query_id=TPCH-07, scale_factor=1
  • tpch (R) with engine=arrow, format=native, language=R, memory_map=False, query_id=TPCH-09, scale_factor=1
• and 69 more (see the report linked below)

There were no benchmark performance regressions. 🎉

The full Conbench report has more details. It also includes information about 17 possible false positives for unstable benchmarks that are known to sometimes produce them.