Deno 1.43.2 homebrew build segmentation fault

[jerome-benoit]

brew gist-logs <formula> link OR brew config AND brew doctor output

N/A

Verification

• My brew doctor output says Your system is ready to brew. and am still able to reproduce my issue.
• I ran brew update and am still able to reproduce my issue.
• I have resolved all warnings from brew doctor and that did not fix my problem.
• I searched for recent similar issues at https://github.com/Homebrew/homebrew-core/issues?q=is%3Aissue and found no duplicates.

What were you trying to do (and why)?

The code in https://github.com/poolifier/poolifier-web-worker/tree/master/examples/deno/typescript segfault with Deno homebrew build version 1.43.2:

[1] 30111 segmentation fault deno run -A pool.ts

All UTs instantiating a pool are also triggering a segfault.

Deno homebrew build version 1.43.1 and official Deno.com binaries works fine.

What happened (include all command output)?

N/A

What did you expect to happen?

N/A

Step-by-step reproduction instructions (by running brew commands)

N/A

[mmastrac]

Minimal repro:

deno eval "fetch('http://8.8.8.8')"

[mmastrac]

(lldb) bt
* thread #1, name = 'main', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x00000001965467fc libsystem_platform.dylib`_platform_memmove + 444
    frame #1: 0x00000001003b1134 deno`_$LT$alloc..string..String$u20$as$u20$core..fmt..Write$GT$::write_str::h0cd0257f8894a894 (.78) + 60
    frame #2: 0x000000010048879c deno`core::fmt::write::hef5cddb56c038e23 + 412
    frame #3: 0x00000001011385d4 deno`_$LT$serde_v8..error..Error$u20$as$u20$core..fmt..Display$GT$::fmt::h6d6357bd95d56e19 + 788
    frame #4: 0x000000010048879c deno`core::fmt::write::hef5cddb56c038e23 + 412
    frame #5: 0x00000001003cceb0 deno`anyhow::error::_$LT$impl$u20$core..fmt..Display$u20$for$u20$anyhow..Error$GT$::fmt::hc813d512ad8949cb + 96
    frame #6: 0x000000010048879c deno`core::fmt::write::hef5cddb56c038e23 + 412
    frame #7: 0x00000001003b1088 deno`alloc::fmt::format::format_inner::hcf93ae4763afd4b5 + 296
    frame #8: 0x0000000100cf8240 deno`deno_fetch::op_fetch::op_fetch$LT$FP$GT$::v8_fn_ptr::h86e6e97f373d448e + 188
    frame #9: 0x00000001025fef98 deno`Builtins_CallApiCallbackGeneric + 184
    frame #10: 0x00000001025fcef0 deno`Builtins_InterpreterEntryTrampoline + 272
    frame #11: 0x00000001025fcef0 deno`Builtins_InterpreterEntryTrampoline + 272
    frame #12: 0x00000001027023a0 deno`Builtins_PromiseConstructor + 2400
    frame #13: 0x00000001025fdc78 deno`construct_stub_invoke_deopt_addr + 256
    frame #14: 0x0000000102773270 deno`Builtins_ConstructHandler + 880
    frame #15: 0x00000001025fcef0 deno`Builtins_InterpreterEntryTrampoline + 272
    frame #16: 0x00000001025fcef0 deno`Builtins_InterpreterEntryTrampoline + 272
    frame #17: 0x000000010263b5a4 deno`Builtins_GeneratorPrototypeNext + 132
    frame #18: 0x00000001025fac0c deno`Builtins_JSEntryTrampoline + 172
    frame #19: 0x00000001025fa8f4 deno`Builtins_JSEntry + 148
    frame #20: 0x0000000101609730 deno`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 1608
    frame #21: 0x0000000101609fa0 deno`v8::internal::(anonymous namespace)::InvokeWithTryCatch(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 88
    frame #22: 0x000000010160a06c deno`v8::internal::Execution::TryCall(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*, v8::internal::Execution::MessageHandling, v8::internal::MaybeHandle<v8::internal::Object>*) + 120
    frame #23: 0x00000001019a0b68 deno`v8::internal::SourceTextModule::ExecuteModule(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SourceTextModule>, v8::internal::MaybeHandle<v8::internal::Object>*) + 156
    frame #24: 0x00000001019a0354 deno`v8::internal::SourceTextModule::InnerModuleEvaluation(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SourceTextModule>, v8::internal::ZoneForwardList<v8::internal::Handle<v8::internal::SourceTextModule>>*, unsigned int*) + 968
    frame #25: 0x000000010199fe4c deno`v8::internal::SourceTextModule::Evaluate(v8::internal::Isolate*, v8::internal::Handle<v8::internal::SourceTextModule>) + 232
    frame #26: 0x000000010196e96c deno`v8::internal::Module::Evaluate(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Module>) + 272
    frame #27: 0x0000000101515474 deno`v8::Module::Evaluate(v8::Local<v8::Context>) + 540
    frame #28: 0x00000001005653b0 deno`deno_core::modules::map::ModuleMap::mod_evaluate::hf44916c1c16b2045 + 528
    frame #29: 0x00000001005e4308 deno`deno_core::runtime::jsruntime::JsRuntime::mod_evaluate::h0e07d500fdf7e313 + 60
    frame #30: 0x00000001000f8358 deno`deno::worker::CliMainWorker::evaluate_module_possibly_with_npm::_$u7b$$u7b$closure$u7d$$u7d$::hf71662aaf868eee2 + 364
    frame #31: 0x0000000100145328 deno`deno::worker::CliMainWorker::execute_main_module_possibly_with_npm::_$u7b$$u7b$closure$u7d$$u7d$::hba55f853210870e4 + 832
    frame #32: 0x00000001001446a4 deno`deno::worker::CliMainWorker::run::_$u7b$$u7b$closure$u7d$$u7d$::h7173fcd5639f5c51 + 1108
    frame #33: 0x000000010033a4fc deno`deno::spawn_subcommand::_$u7b$$u7b$closure$u7d$$u7d$::hcbe870bd72885b6e + 924
    frame #34: 0x0000000100379d70 deno`_$LT$deno_unsync..task..MaskFutureAsSend$LT$F$GT$$u20$as$u20$core..future..future..Future$GT$::poll::h9df2cefee1c7d85b + 40
    frame #35: 0x000000010037a078 deno`tokio::runtime::task::raw::poll::heefa63eb0fc35a17 + 88
    frame #36: 0x0000000100013b8c deno`deno::main::h2177c5e647eb4673 + 4560
    frame #37: 0x0000000100006cb4 deno`std::sys_common::backtrace::__rust_begin_short_backtrace::hf003e1d37bf08e70 + 12
    frame #38: 0x0000000100012734 deno`main + 656
    frame #39: 0x00000001961bff28 dyld`start + 2236

[Bo98]

The only difference I can see is that we updated Rust to 1.78.0 in the interim. Perhaps Deno has issues with Rust 1.78?

We don't ship Rust 1.77 anymore so will need to figure out a fix for 1.78 if so.

[mmastrac]

We're unfortunately blocked on 1.78 (EDIT: to clarify, blocked on upgrading to 1.78) on the deno side because of an LLVM-18 issue (the current packages don't include the linker) so we haven't done any testing there yet.

I'm not sure but we might be able to build Mac on 1.78 and Linux on 1.77 for now to see if it repros on our end.

[jerome-benoit]

We're unfortunately blocked on 1.78 on the deno side because of an LLVM-18 issue (the current packages don't include the linker) so we haven't done any testing there yet.

You mean 1.77, right?

[chenrui333]

the downgrade to 1.43.1 works fine for me (with the fresh test, which failed with 1.43.2)

$ clang --version
Homebrew clang version 18.1.5
Target: arm64-apple-darwin23.4.0
Thread model: posix
InstalledDir: /opt/homebrew/Cellar/llvm/18.1.5/bin


$ rustc --version
rustc 1.78.0 (9b00956e5 2024-04-29) (Homebrew)

$ brew test -d -v deno
/opt/homebrew/Library/Homebrew/vendor/bundle/ruby/3.1.0/bin/bundle clean
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromNameLoader): loading deno
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromTapLoader): loading homebrew/core/deno
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromNameLoader): loading cmake
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromNameLoader): loading llvm
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromNameLoader): loading ninja
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromNameLoader): loading protobuf
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromNameLoader): loading rust
/opt/homebrew/Library/Homebrew/brew.rb (Formulary::FromNameLoader): loading sqlite
==> Testing deno
/opt/homebrew/Library/Homebrew/test.rb (Formulary::FromPathLoader): loading /opt/homebrew/Library/Taps/homebrew/homebrew-core/Formula/d/deno.rb
==> /opt/homebrew/Cellar/deno/1.43.1/bin/deno run hello.ts
==> /opt/homebrew/Cellar/deno/1.43.1/bin/deno run https://deno.land/std@0.100.0/examples/welcome.ts
/opt/homebrew/Library/Homebrew/test.rb (Formulary::FromNameLoader): loading sqlite

also I can reproduce this with deno 1.43.2, but not with deno 1.43.1

$ deno eval "fetch('http://8.8.8.8')"
Segmentation fault: 11

[mmastrac]

You mean 1.77, right?

No, we can't upgrade to 1.78 for Linux builds because our sysroot build fails using the llvm-17 package we install from apt.llvm.org.

Bug is here: denoland/deno#23676

Upstream LLVM issue here: llvm/llvm-project#87553

[mmastrac]

I found some UB in deno_core that is likely causing this. Rust 1.78 seems to have been the trigger for it to start failing, but the code was certainly busted for a while.

denoland/deno_core#735

This should be fixed in 1.43.3.

[jerome-benoit]

You mean 1.77, right?

No, we can't upgrade to 1.78 for Linux builds because our sysroot build fails using the llvm-17 package we install from apt.llvm.org.

That's what you mean but wrote 1.78 (typo) ;). Nevermind, explanations are clear.

[carlocab]

As a workaround:

brew tap --force homebrew/core
cd "$(brew --repository homebrew/core)"
git checkout bf2314dc93067e2c6dd108279244ac3740b568e6
HOMEBREW_NO_INSTALL_FROM_API=1 brew install deno
git checkout master
# skip the command below if you contribute to homebrew/core
brew untap homebrew/core

[carlocab]

Not quite fixed yet. Merged PR is merely a workaround.

[mmastrac]

Here's what appears to be happening:

• Some fairly old (~2yrs+) code was using a bit of a sketchy reference -> pointer -> u64 conversion to values that were live on the stack (!). This is definitely bad.
• This worked fine in 1.77, even passing valgrind tests!
• This code breaks in Rust 1.78, likely because some of the types that were being passed on the stack previously might be in registers now, or might be in stack locations that are overwritten
• We never picked this up in our tests because we're blocked on upgrading to Rust 1.78 and stuck on 1.77 for now. We can, however, bump deno_core up to 1.78 to ensure that we test those parts of the code on the newer compiler.

We're going to fix the UB here by boxing the values. It's a band-aid fix but we consider this code to be EOL and we're actively working on replacing it.

denoland/deno_core#735

[mmastrac]

Deno 1.43.3 incoming -- should fix this issue.

[jerome-benoit]

#171423

The deno formula downgrade to 1.43.1 is not installed over installed 1.43.2 formula:

Warning: Skipping deno: most recent version 1.43.1 not installed

[carlocab]

Yes, #171382 was just meant to prevent more users from upgrading to a broken build. If you've already done so, you need to do brew reinstall deno.

[carlocab]

Should be fixed in #171423 which will merge shortly.

Do brew update && brew upgrade deno in about 20 minutes or so.