Segmentation fault (core dumped) error at startup on v1.46+

[nberlette]

Version: Deno v1.46.1

I'm unable to import any of the files from my project starting with v1.46. Everything worked fine in v1.45.5.

To demonstrate, I've attached a quick screen recording below where I first attempt to start up the REPL and import a function named alias. It fails with a segfault error in v1.46.1. I then downgrade to v1.45.5 and attempt the same exact thing, and it imports it with no issues at all.

https://github.com/user-attachments/assets/fdf1c3d5-4458-4346-93cb-bdd74f398525

[littledivy]

I am not able to reproduce on Linux. Can you provide backtrace from a debugger like lldb?

[nberlette]

Of course. I'll run a backtrace on it shortly and post the results as soon as I have them

On Aug 23, 2024, at 8:56 PM, Divy Srivastava @.***> wrote:

I am not able to reproduce on Linux. Can you provide backtrace from a debugger like lldb?

— Reply to this email directly, view it on GitHub https://github.com/denoland/deno/issues/25192#issuecomment-2308039194, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVWWOGOOOJLLP7BBZPZEGTZTAAABAVCNFSM6AAAAABNBDNQB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGAZTSMJZGQ. You are receiving this because you authored the thread.

[nberlette]

@littledivy Sorry it took so long. This isn't on my local machine (it's on a codespace instance) and I ran into a bunch of config issues trying to get lldb to work.

Here's the backtrace output from rust-lldb. I only included the real meat of the log, but if you want the entire thing just let me know. This seems to be the only relevant part though.

Thanks for your help!

* thread #4, name = 'tokio-runtime-w', stop reason = signal SIGSEGV: invalid permissions for mapped object (fault address: 0x79934c07dc20)
    frame #0: 0x000079934c07dc20
->  0x79934c07dc20: andb   $0x0, %al
    0x79934c07dc22: addb   %al, (%rax)
    0x79934c07dc24: xchgl  %ebx, %eax
    0x79934c07dc25: jns    0x79934c07dc27
(lldb) bt
* thread #4, name = 'tokio-runtime-w', stop reason = signal SIGSEGV: invalid permissions for mapped object (fault address: 0x79934c07dc20)
  * frame #0: 0x000079934c07dc20
    frame #1: 0x0000799360b91879 libgcc_s.so.1`___lldb_unnamed_symbol276 + 137
    frame #2: 0x0000799360b9214d libgcc_s.so.1`_Unwind_Resume + 397
    frame #3: 0x000061c20f10cebf deno`_$LT$swc_ecma_ast..typescript..TsAsExpr$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_children_with::h821af894161de02f + 46
    frame #4: 0x000061c20f1063c7 deno`_$LT$alloc..boxed..Box$LT$T$GT$$u20$as$u20$swc_visit..util..map..Map$LT$T$GT$$GT$::map::hbf3c018b981e4f8a + 3085
    frame #5: 0x000061c20f10633e deno`_$LT$alloc..boxed..Box$LT$T$GT$$u20$as$u20$swc_visit..util..map..Map$LT$T$GT$$GT$::map::hbf3c018b981e4f8a + 2948
    frame #6: 0x000061c20f10acd4 deno`_$LT$swc_ecma_ast..expr..ParenExpr$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_children_with::ha84f8e55acaf1737 + 25
    frame #7: 0x000061c20f10600b deno`_$LT$alloc..boxed..Box$LT$T$GT$$u20$as$u20$swc_visit..util..map..Map$LT$T$GT$$GT$::map::hbf3c018b981e4f8a + 2129
    frame #8: 0x000061c20f10ceaa deno`_$LT$swc_ecma_ast..typescript..TsAsExpr$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_children_with::h821af894161de02f + 25
    frame #9: 0x000061c20f1063c7 deno`_$LT$alloc..boxed..Box$LT$T$GT$$u20$as$u20$swc_visit..util..map..Map$LT$T$GT$$GT$::map::hbf3c018b981e4f8a + 3085
    frame #10: 0x000061c20f1044ee deno`core::option::Option$LT$T$GT$::map::h74d952dd1bf9be3b + 17
    frame #11: 0x000061c20f10732b deno`_$LT$swc_ecma_ast..stmt..Stmt$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_children_with::hd26d207793b1840d + 339
    frame #12: 0x000061c20f10d1f2 deno`_$LT$swc_ecma_utils..constructor..Injector$u20$as$u20$swc_ecma_visit..generated..Fold$GT$::fold_stmts::h62eec68dfd27330c + 270
    frame #13: 0x000061c20f10adcf deno`_$LT$swc_ecma_ast..stmt..BlockStmt$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_children_with::h5052d946927a2b3c + 28
    frame #14: 0x000061c20f1076e6 deno`_$LT$swc_ecma_ast..stmt..Stmt$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_children_with::hd26d207793b1840d + 1294
    frame #15: 0x000061c20f10d1f2 deno`_$LT$swc_ecma_utils..constructor..Injector$u20$as$u20$swc_ecma_visit..generated..Fold$GT$::fold_stmts::h62eec68dfd27330c + 270
    frame #16: 0x000061c20f10adcf deno`_$LT$swc_ecma_ast..stmt..BlockStmt$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_children_with::h5052d946927a2b3c + 28
    frame #17: 0x000061c20f104550 deno`core::option::Option$LT$T$GT$::map::hc509a84199d50949 (.llvm.11817459882730434308) + 32
    frame #18: 0x000061c20f10cfeb deno`swc_ecma_utils::constructor::inject_after_super::hf9b6586d23b834b9 + 81
    frame #19: 0x000061c20f05ea6f deno`_$LT$swc_ecma_transforms_proposal..decorator_2022_03..Decorator2022_03$u20$as$u20$swc_ecma_visit..generated..VisitMut$GT$::visit_mut_class::h661318c16f611d29 + 624
    frame #20: 0x000061c20f065c9e deno`_$LT$swc_ecma_transforms_proposal..decorator_2022_03..Decorator2022_03$u20$as$u20$swc_ecma_visit..generated..VisitMut$GT$::visit_mut_module_items::hd975114cd76889d7 + 754
    frame #21: 0x000061c20eff19a2 deno`_$LT$swc_ecma_ast..module..Program$u20$as$u20$swc_ecma_visit..generated..FoldWith$LT$V$GT$$GT$::fold_with::he57b76433bfcdae6 + 1738
    frame #22: 0x000061c20f0153b6 deno`deno_ast::transpiling::fold_program::h13b0c8ce7d8d627a + 4297
    frame #23: 0x000061c20f013e07 deno`deno_ast::transpiling::transpile::hd4122acdc0a3ba69 + 285
    frame #24: 0x000061c20f013673 deno`deno_ast::transpiling::_$LT$impl$u20$deno_ast..parsed_source..ParsedSource$GT$::transpile::he6239135a75f8987 + 577
    frame #25: 0x000061c20d4b4142 deno`deno::emit::EmitParsedSourceHelper::transpile::h9e6bdeabdf331285 + 754
    frame #26: 0x000061c20d31c0f5 deno`tokio::runtime::task::raw::poll::h8762b0edd1042283 + 221
    frame #27: 0x000061c20f40f590 deno`std::sys_common::backtrace::__rust_begin_short_backtrace::h441af42626d0a10d + 432
    frame #28: 0x000061c20f411d12 deno`core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h506cb4efabbeeb1b + 162
    frame #29: 0x000061c20d0c032b deno`std::sys::pal::unix::thread::Thread::new::thread_start::hb85dbfa54ba503d6 + 43
    frame #30: 0x0000799360b5cea7 libpthread.so.0`start_thread + 215
    frame #31: 0x0000799360938a6f libc.so.6`__clone + 63

[nberlette]

@littledivy based on the backtrace line frame #19: ... _$LT$swc_ecma_transforms_proposal..decorator_2022_03, I figured it must be at least related to the SWC decorators helper. So I tried removing all traces of decorators from one particular file, and bingo, it works as it should.

---

[!NOTE] Upon further inspection, it appears my previous statements were incorrect, and so I both apologize and retract what I said regarding the footprint of this bug. This appears now to be something specifically caused by the right combination of conditions in my particular codebase. It is not preventing the usage of Stage 3 decorators entirely, and it should not be impeding everyday users from being able to use them in their project. Sorry for jumping to conclusions 😟

[bartlomieju]

@nberlette can you share your code that uses decorators that caused this problem?

[nberlette]

@bartlomieju I've done some further investigation and narrowed down the issue. It looks like the error is specifically triggered by the use of the @bind decorator on a getter in one of the classes. This class is used extensively across the monorepo, which initially led me to mistakenly think the problem was with all decorators. I realized this mistake last night and meant to update my previous comments, but it seems I forgot to hit submit. Sorry about that.

I've included a simplified example of the code below. However, this snippet doesn't reproduce the segfault on its own, so it's unlikely to be very helpful without additional context. This bug is proving to be particularly elusive, and giving me some difficultly in coming up with an isolated minimal reproduction. Since the repo isn't public yet, I'm reluctant to share the full source here... but I'm more than happy to send you the complete file (or even the whole module graph) through a more private channel (email or Discord?) if that works for you.

// Simplified version of the working code
class WeakStorage<K extends WeakKey, V> {
  #storage = new WeakMap<WeakCollection<K, V>, WeakStorageArea<K, V>>();

  // Without the @bind decorator on 'storage', this works fine
  get storage(): WeakStorageArea {
    return this.#storage;
  }

  // ... 
}

// However, when I add the 'bind' decorator to the 'storage' getter (with no other changes) -> segfault
import { bind } from "jsr:@decorators/bind@^0.1.2";

class WeakStorage<K extends WeakKey, V> {
  #storage = new WeakMap<WeakCollection<K, V>, WeakStorageArea>();

  @bind get storage(): WeakStorageArea {
    return this.#storage;
  }

  // ...
}

[bartlomieju]

Yeah Discord would definitely work, thanks!

[greentore]

I ran into this issue as well. And in my case it was caused by... as any assertion. I have a class with methods decorated with a memo decorator and the code refuses to run (no error or anything) if there's any assertion in the constructor. Here's a minimal reproduction:

function memo(
  fn: (this: Data, id: number) => string,
  _ctx: ClassMethodDecoratorContext,
) {
  const cache = new Map<number, string>();
  return function (this: Data, id: number): string {
    const val = cache.get(id);
    if (val) return val;
    const str = fn.call(this, id);
    cache.set(id, str);
    return str;
  };
}

export class Data {
  constructor() {
    const a = 1 as any;
  }

  @memo
  m(id: number): string {
    return "";
  }
}