deps: update v8 to 13.8.258.26

[leonm1]

Commit Message: deps: update v8 to 13.8.258.26
Additional Description:

Includes the requisite updates to proxy_wasm_cpp_host and new v8 dependencies.

Tested with bazel test test/extensions/filters/http/wasm/... --define wasm=v8 (and --define wasm=wasmtime and --define wasm=wamr for defense in depth).

Proxy-wasm-cpp-host patches come from proxy-wasm/proxy-wasm-cpp-host#442

Risk Level:
Testing: Tested with `bazel test test/extensions/filters/http/wasm/... --define
Docs Changes: None.
Release Notes: None.
Platform Specific Features: None.
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Fixes commit #PR or SHA]
[Optional Deprecated:]
[Optional API Considerations:]

Fix #28336

[repokitteh-read-only]

CC @envoyproxy/dependency-shepherds: Your approval is needed for changes made to (bazel/.*repos.*\.bzl)|(bazel/dependency_imports\.bzl)|(api/bazel/.*\.bzl)|(.*/requirements\.txt)|(.*\.patch).
envoyproxy/dependency-shepherds assignee is @RyanTheOptimist

🐱

Caused by: #40305 was opened by leonm1.

see: more, trace.

[agrawroh]

This is great! LGTM for deps.

[agrawroh]

@leonm1 Looks like deps CI is failing:
https://github.com/envoyproxy/envoy/actions/runs/16381192670/job/46292917457

Could you PTAL?

[phlax]

@leonm1 thanks for this

there appears to be 2 issues

missing @intel_ittapi dep - i tried adding this as an implied_untracked_dep but it appears that it is actually required so will need to be added to repository_locations.bzl etc

dependency on libatomic - there appears to be a dependency on a shared libatomic dep, which envoy cannot ship with

afaict we dont actually need it for arm64 or x86_64 so probably the easiest solution is to patch the v8 build to not include it here https://github.com/v8/v8/blob/0cc9073898540c8f1f8c515a2a3aa214ac67ba6d/bazel/defs.bzl#L184

[leonm1]

I'm running into a flaky TSAN failure (building on Envoy RBE):

I don't see how it's related to V8, but it doesn't flake at main.

exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from //test/extensions/filters/http/wasm:wasm_filter_integration_test
-----------------------------------------------------------------------------
Note: This is test shard 13 of 16.
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from Runtimes/WasmFilterIntegrationTest
[ RUN      ] Runtimes/WasmFilterIntegrationTest.BodyBufferedMultipleChunksManipulation/downstream_v8_cpp_http1
[2025-07-21 18:43:50.714][18][critical][assert] [test/integration/base_integration_test.cc:480] assert failure: 0. Details: Timed out waiting for listeners.
[2025-07-21 18:43:50.715][18][error][envoy_bug] [./source/common/common/assert.h:38] stacktrace for envoy bug
[2025-07-21 18:43:50.934][18][error][envoy_bug] [./source/common/common/assert.h:43] #0 Envoy::BaseIntegrationTest::createGeneratedApiTestServer() [0x55d7ce862e5c]
[2025-07-21 18:43:51.054][18][error][envoy_bug] [./source/common/common/assert.h:43] #1 Envoy::BaseIntegrationTest::createGeneratedApiTestServer() [0x55d7ce85e67e]
[2025-07-21 18:43:51.196][18][error][envoy_bug] [./source/common/common/assert.h:43] #2 Envoy::BaseIntegrationTest::createEnvoy() [0x55d7ce85e51d]
[2025-07-21 18:43:51.300][18][error][envoy_bug] [./source/common/common/assert.h:43] #3 Envoy::BaseIntegrationTest::initialize() [0x55d7ce85b2ba]
[2025-07-21 18:43:51.405][18][error][envoy_bug] [./source/common/common/assert.h:43] #4 Envoy::HttpIntegrationTest::initialize() [0x55d7cdfbaddd]
[2025-07-21 18:43:51.508][18][error][envoy_bug] [./source/common/common/assert.h:43] #5 Envoy::Extensions::Wasm::(anonymous namespace)::WasmFilterIntegrationTest_BodyBufferedMultipleChunksManipulation_Test::TestBody() [0x55d7c4c8f0d2]
[2025-07-21 18:43:51.612][18][error][envoy_bug] [./source/common/common/assert.h:43] #6 Envoy::Extensions::Wasm::(anonymous namespace)::WasmFilterIntegrationTest_BodyBufferedMultipleChunksManipulation_Test::TestBody() [0x55d7c4c8fe2d]
[2025-07-21 18:43:51.716][18][error][envoy_bug] [./source/common/common/assert.h:43] #7 testing::internal::HandleSehExceptionsInMethodIfSupported<>() [0x55d7d5ce29bd]
[2025-07-21 18:43:51.821][18][error][envoy_bug] [./source/common/common/assert.h:43] #8 testing::internal::HandleExceptionsInMethodIfSupported<>() [0x55d7d5caed8b]
[2025-07-21 18:43:51.926][18][error][envoy_bug] [./source/common/common/assert.h:43] #9 testing::Test::Run() [0x55d7d5c8a239]
[2025-07-21 18:43:52.031][18][error][envoy_bug] [./source/common/common/assert.h:43] #10 testing::TestInfo::Run() [0x55d7d5c8b06d]
[2025-07-21 18:43:52.135][18][error][envoy_bug] [./source/common/common/assert.h:43] #11 testing::TestSuite::Run() [0x55d7d5c8bde0]
[2025-07-21 18:43:52.240][18][error][envoy_bug] [./source/common/common/assert.h:43] #12 testing::internal::UnitTestImpl::RunAllTests() [0x55d7d5c9e600]
[2025-07-21 18:43:52.345][18][error][envoy_bug] [./source/common/common/assert.h:43] #13 testing::internal::HandleSehExceptionsInMethodIfSupported<>() [0x55d7d5ce7cc0]
[2025-07-21 18:43:52.451][18][error][envoy_bug] [./source/common/common/assert.h:43] #14 testing::internal::HandleExceptionsInMethodIfSupported<>() [0x55d7d5cb279b]
[2025-07-21 18:43:52.557][18][error][envoy_bug] [./source/common/common/assert.h:43] #15 testing::UnitTest::Run() [0x55d7d5c9db9f]
[2025-07-21 18:43:52.558][18][critical][backtrace] [./source/server/backtrace.h:129] Caught Aborted, suspect faulting address 0xfffe00000012
[2025-07-21 18:43:52.558][18][critical][backtrace] [./source/server/backtrace.h:113] Backtrace (use tools/stack_decode.py to get line numbers):
[2025-07-21 18:43:52.559][18][critical][backtrace] [./source/server/backtrace.h:114] Envoy version: 0/1.35.0-dev/test/DEBUG/BoringSSL
==================
WARNING: ThreadSanitizer: signal-unsafe call inside of a signal (pid=18)
    #0 malloc ??:? (wasm_filter_integration_test+0x592eb8c)
    #1 operator new(unsigned long) ??:? (wasm_filter_integration_test+0x16c72907)
    #2 Envoy::BackwardsTrace::addrMapping(bool) ??:? (wasm_filter_integration_test+0x14acf25c)
    #3 Envoy::BackwardsTrace::logTrace() ??:? (wasm_filter_integration_test+0x14ac40af)
    #4 Envoy::SignalAction::sigHandler(int, siginfo_t*, void*) ??:? (wasm_filter_integration_test+0x14ac05a6)
    #5 __tsan::CallUserSignalHandler(__tsan::ThreadState*, bool, bool, int, __sanitizer::__sanitizer_siginfo*, void*) tsan_interceptors_posix.cpp:? (wasm_filter_integration_test+0x5937ef5)
    #6 Envoy::BaseIntegrationTest::createGeneratedApiTestServer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, Envoy::Server::FieldValidationConfig, bool, std::__1::unique_ptr<Envoy::IntegrationTestServer, std::__1::default_delete<Envoy::IntegrationTestServer> >&) ??:? (wasm_filter_integration_test+0xf590e76)
    #7 Envoy::BaseIntegrationTest::createGeneratedApiTestServer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, std::__1::allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&, Envoy::Server::FieldValidationConfig, bool) ??:? (wasm_filter_integration_test+0xf58c67d)
    #8 Envoy::BaseIntegrationTest::createEnvoy() ??:? (wasm_filter_integration_test+0xf58c51c)
    #9 Envoy::BaseIntegrationTest::initialize() ??:? (wasm_filter_integration_test+0xf5892b9)
    #10 Envoy::HttpIntegrationTest::initialize() ??:? (wasm_filter_integration_test+0xece8ddc)
    #11 Envoy::Extensions::Wasm::(anonymous namespace)::WasmFilterIntegrationTest_BodyBufferedMultipleChunksManipulation_Test::TestBody() wasm_filter_integration_test.cc:? (wasm_filter_integration_test+0x59bd0d1)
    #12 non-virtual thunk to Envoy::Extensions::Wasm::(anonymous namespace)::WasmFilterIntegrationTest_BodyBufferedMultipleChunksManipulation_Test::TestBody() wasm_filter_integration_test.cc:? (wasm_filter_integration_test+0x59bde2c)
    #13 void testing::internal::HandleSehExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ??:? (wasm_filter_integration_test+0x16a109bc)
    #14 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) ??:? (wasm_filter_integration_test+0x169dcd8a)
    #15 testing::Test::Run() ??:? (wasm_filter_integration_test+0x169b8238)
    #16 testing::TestInfo::Run() ??:? (wasm_filter_integration_test+0x169b906c)
    #17 testing::TestSuite::Run() ??:? (wasm_filter_integration_test+0x169b9ddf)
    #18 testing::internal::UnitTestImpl::RunAllTests() ??:? (wasm_filter_integration_test+0x169cc5ff)
    #19 bool testing::internal::HandleSehExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ??:? (wasm_filter_integration_test+0x16a15cbf)
    #20 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) ??:? (wasm_filter_integration_test+0x169e079a)
    #21 testing::UnitTest::Run() ??:? (wasm_filter_integration_test+0x169cbb9e)
    #22 RUN_ALL_TESTS() ??:? (wasm_filter_integration_test+0x14215117)
    #23 Envoy::TestRunner::runTests(int, char**) ??:? (wasm_filter_integration_test+0x14214329)
    #24 main ??:? (wasm_filter_integration_test+0x14211a8d)

SUMMARY: ThreadSanitizer: signal-unsafe call inside of a signal ??:? in malloc
==================
[2025-07-21 18:43:54.126][18][critical][backtrace] [./source/server/backtrace.h:121] #0: Envoy::SignalAction::sigHandler() [0x55d7d3d9257b]
[2025-07-21 18:43:54.227][18][critical][backtrace] [./source/server/backtrace.h:121] #1: __tsan::CallUserSignalHandler() [0x55d7c4c09ef6]

I will continue working on this

[agrawroh]

@leonm1 Feel free to ping me here or on Slack if you are stuck and need any help. TSAN is flaky and is failing on other PRs as well. Hopefully retry would help.

[phlax]

flake discrepancy might be just a caching issue - altho i dont recall seeing that issue previously

[agrawroh]

Looks like the WASM Filter test is timing out, which could be related to this change:
https://github.com/envoyproxy/envoy/actions/runs/16425847484/job/46415823303

[phlax]

i think add size = "large" to that test

its sharded but its got normal timeouts - so increasing sharding is another option - but more sharding means more resources etc and often doesnt help dep on the issue

[leonm1]

@phlax —

dependency on libatomic - there appears to be a dependency on a shared libatomic dep, which envoy cannot ship with

afaict we dont actually need it for arm64 or x86_64 so probably the easiest solution is to patch the v8 build to not include it here https://github.com/v8/v8/blob/0cc9073898540c8f1f8c515a2a3aa214ac67ba6d/bazel/defs.bzl#L184

I removed the linker flag for libatomic, and it works properly on x86_64; however, it appears to be required for aarch64 (from proxy-wasm CI):

ERROR: /home/runner/work/proxy-wasm-cpp-host/proxy-wasm-cpp-host/test/BUILD:86:8: Linking test/exports_test failed: (Exit 1): cc_wrapper.sh failed: error executing command (from target //test:exports_test) 
  (cd /home/runner/.cache/bazel/_bazel_runner/ae21fb6b2e26a9267f16b46bb90ea321/sandbox/processwrapper-sandbox/3160/execroot/proxy_wasm_cpp_host && \
  exec env - \
    BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1 \
    PATH=/home/runner/.cache/bazelisk/downloads/sha256/a40ac69263440761199fcb8da47ad4e3f328cbe79ffbf4ecc14e5ba252857307/bin:/snap/bin:/home/runner/.local/bin:/opt/pipx_bin:/home/runner/.cargo/bin:/home/runner/.config/composer/vendor/bin:/usr/local/.ghcup/bin:/home/runner/.dotnet/tools:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin \
    *** \
  external/llvm_aarch64/bin/cc_wrapper.sh @bazel-out/k8-fastbuild/bin/test/exports_test-2.params)
# Configuration: 69abc187a70dbfe2c50107aa4e8cd91518b036382bbc9a23d3e591d7af44cb59
# Execution platform: @local_config_platform//:host

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
ld.lld: error: undefined symbol: __atomic_compare_exchange
>>> referenced by wasm-code-manager.cc
>>>               bazel-out/k8-fastbuild/bin/external/v8/_objs/v8_libshared_noicu/wasm-code-manager.pic.o:(std::atomic<v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead>::compare_exchange_strong(v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead&, v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead, std::memory_order, std::memory_order))
>>> referenced by wasm-code-manager.cc
>>>               bazel-out/k8-fastbuild/bin/external/v8/_objs/v8_libshared_noicu/wasm-code-manager.pic.o:(std::atomic<v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead>::compare_exchange_strong(v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead&, v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead, std::memory_order, std::memory_order))
>>> referenced by wasm-code-manager.cc
>>>               bazel-out/k8-fastbuild/bin/external/v8/_objs/v8_libshared_noicu/wasm-code-manager.pic.o:(std::atomic<v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead>::compare_exchange_strong(v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead&, v8::internal::SegmentedTable<v8::internal::wasm::WasmCodePointerTableEntry, 134217728ul>::FreelistHead, std::memory_order, std::memory_order))
>>> referenced 57 more times

We do cross-compile our aarch64 build, so it is possible it works on a native aarch64 build, but I don't have such a machine to test.

[phlax]

I don't have such a machine to test.

arm64 vms are for free for OSS on github now

[phlax]

im more concerned about the tsan fail - otoh its the only thing that is failing, otoh it looks more permafail than flake - so wondering why the v8 change would trigger it

cc @ravenblackx

[leonm1]

I was able to fix the V8 TSAN flake by increasing the listeners bind timeout:

// Up from 10 * TestUtility::DefaultTimeout
setListenersBoundTimeout(20 * TestUtility::DefaultTimeout);

Passes with --runs_per_test=10 now

[phlax]

so wrt patching v8 - we could do that in our repo for now

i think this will be revisited for other arches - but if we can make it work for arm/x86 that works for us

ideally we reduce/eliminate all patches by upstreaming, but that can be slow

i was going to mention about moving the patches upstream from envoy

makes sense if its more generally useful - but at least in some cases it was interaction with other deps - eg rules_python - so we might need to ~fork the patches back in future etc - which really underlines why we want to reduce patches as much as possible

[agrawroh]

This is from 2021. Are we sure that we want to use this version?

[phlax]

this is the version set upstream

see https://github.com/v8/v8/blob/cac6de03372c25987c6cbea49b4b39d9da437978/DEPS#L297

[isker]

cloudflare/workerd#3891 Prior art on libatomic. Workerd does build for aarch64.

[phlax]

@leonm1 i took the liberty of pushing some commits to resolve remaining issues as we are hoping to land this asap before cutting a release

i tested the wasm tests - using RBE - locally - seems like all these tests benefit from more cores - and adding for config_test got it over the timeout line

im not sure if the sharding is optimal - some shards take ~2s - so probs they are not actually getting any tests - also it seems like bazel uses name based sharding - so i think it might be grouping all the slowest tests into one shard

[phlax]

lgtm, thanks @leonm1 - really appreciated

[moderation]

As per the comments in the original draft PR - #40235 - the OSSF Scorecard scores for a lot of these new dependencies were bad. Was it possible to address with newer versions or upstream fixes?

[phlax]

the newer version of v8 is what dragged in a bunch of dependencies - and they seemed, at least without even more patching/complexity, required

the benefit of updating is that we dont have to worry about a load of cves - so i think we needed to land, not sure if we can encourage upstreams to improve scores - i noticed that there was some history in that respect when i was looking at this today