Segmentation faults in napi v2.10.3 and later

[devongovett]

I'm trying to update the Parcel source map package to the latest napi version (parcel-bundler/source-map#120). In v2.10.3 and later versions, I am getting many different segmentation faults when running within a Parcel build. In v2.10.2, I haven't been able to reproduce these.

  * frame #0: 0x00000001312e4c10 index.darwin-arm64.node`_rjem_sdallocx + 1860
    frame #1: 0x0000000131297e08 index.darwin-arm64.node`core::ptr::drop_in_place$LT$parcel_sourcemap..SourceMapInner$GT$::h50efa85905e8c8e4 + 360
    frame #2: 0x0000000131298294 index.darwin-arm64.node`napi::bindgen_runtime::raw_finalize_unchecked::h42b2d979e71f3af9 + 164
    frame #3: 0x00000001000875f8 node`void napi_env__::CallIntoModule<void node_napi_env__::CallFinalizer<true>(void (*)(napi_env__*, void*, void*), void*, void*)::'lambda'(napi_env__*)&, void node_napi_env__::CallbackIntoModule<true, void node_napi_env__::CallFinalizer<true>(void (*)(napi_env__*, void*, void*), void*, void*)::'lambda'(napi_env__*)>(void node_napi_env__::CallFinalizer<true>(void (*)(napi_env__*, void*, void*), void*, void*)::'lambda'(napi_env__*)&&)::'lambda'(napi_env__*, v8::Local<v8::Value>)>(void node_napi_env__::CallFinalizer<true>(void (*)(napi_env__*, void*, void*), void*, void*)::'lambda'(napi_env__*)&, void node_napi_env__::CallFinalizer<true>(void (*)(napi_env__*, void*, void*), void*, void*)::'lambda'(napi_env__*)&&) + 60

Here's another one:

  * frame #0: 0x00000001303676c4 index.darwin-arm64.node`_rjem_je_large_dalloc + 28
    frame #1: 0x0000000130348c20 index.darwin-arm64.node`_rjem_sdallocx + 1876
    frame #2: 0x0000000130376bfc index.darwin-arm64.node`hashbrown::raw::RawTable$LT$T$C$A$GT$::reserve_rehash::hd989e9f52c061230 + 1600
    frame #3: 0x00000001302fe1cc index.darwin-arm64.node`parcel_sourcemap_node::__napi_impl_helper__JsSourceMap__0::__napi__new::h417a37b0ba7865c1 + 2292

And another:

* thread #14, stop reason = EXC_BAD_ACCESS (code=1, address=0x30)
  * frame #0: 0x000000012a447af8 index.darwin-arm64.node`_rjem_je_extent_heap_remove + 328
    frame #1: 0x000000012a449734 index.darwin-arm64.node`extents_remove_locked + 244
    frame #2: 0x000000012a4483e0 index.darwin-arm64.node`extent_recycle + 472
    frame #3: 0x000000012a4481fc index.darwin-arm64.node`_rjem_je_extents_alloc + 44
    frame #4: 0x000000012a434168 index.darwin-arm64.node`arena_bin_malloc_hard + 312
    frame #5: 0x000000012a433e3c index.darwin-arm64.node`_rjem_je_arena_tcache_fill_small + 556
    frame #6: 0x000000012a45a628 index.darwin-arm64.node`_rjem_je_tcache_alloc_small_hard + 28
    frame #7: 0x000000012a4360cc index.darwin-arm64.node`_rjem_je_arena_ralloc + 1588
    frame #8: 0x000000012a42e890 index.darwin-arm64.node`_rjem_rallocx + 320
    frame #9: 0x000000012a3ec168 index.darwin-arm64.node`alloc::raw_vec::finish_grow::h1d5846dc1bf2fa94 + 80
    frame #10: 0x000000012a3f18e0 index.darwin-arm64.node`parcel_sourcemap_node::__napi_impl_helper__JsSourceMap__0::__napi__add_vlq_map::he681e7f1857f8ee1 + 3728

I did try removing jemalloc and using the system allocator, but it still crashes so I don't think that's the problem. Seems like maybe the pointer to self that's being passed to the class methods is somehow wrong or already dropped.

Looking at the release notes for v2.10.3, #1395 and #1399 stand out as potentially related but not sure. I can keep digging but not really sure what to look for.

Keep in mind that Parcel runs in a multi-threaded Worker environment, so perhaps that is related as well.

[devongovett]

Hmm, with 2.10.2, I see a different segfault involving Buffer:

* thread #17, stop reason = EXC_BAD_ACCESS (code=1, address=0x20a400000010)
  * frame #0: 0x000000010036be44 node`v8::internal::GlobalHandles::Create(v8::internal::Object) + 232
    frame #1: 0x00000001000745b8 node`napi_create_reference + 196
    frame #2: 0x0000000107a10068 index.darwin-arm64.node`_$LT$napi..bindgen_runtime..js_values..buffer..Buffer$u20$as$u20$napi..bindgen_runtime..js_values..FromNapiValue$GT$::from_napi_value::h2481abac2980cdc8 + 64
    frame #3: 0x0000000107a00aac index.darwin-arm64.node`parcel_sourcemap_node::__napi_impl_helper__JsSourceMap__0::__napi__add_json::h8b2a8c9240a2e425 + 864

(This does not occur when I switch to JsBuffer)

[Brooooooklyn]

@devongovett how could I reproduce that, I tried:

• pull the latest @parcel/source-map source codes, checkout to the napi-v2 branch, built it with the latest napi
• ranyarn link
• pull the latest parcel and run yarn link @parcel/source-map
• ranbuild-native-release and test:unit

but it succeeded without any error.

[devongovett]

On the latest commit to that branch I had pinned to v2.10.2. You also might need a large project to test with. I'll get you a repro soon.

[Brooooooklyn]

@devongovett yes, I changed v2.10.2 to 2.11.2 and the test:unit still passed.

[devongovett]

hey sorry for the slow response @Brooooooklyn! I put together a reproduction repo here: https://github.com/devongovett/napi-repro. The steps to reproduce are in the readme. Not sure if it matters, but fwiw I'm testing on an M1 Ultra Mac Studio. I've seen it crash on both Node 16 and 18.

Also we noticed that this doesn't appear limited to the source map package. I also see the same segfaults on other packages using napi classes, including @parcel/hash. Sometimes there is also a double free error before the crash, but that seems to happen more on Node 16.

[devongovett]

Also it seems to be more likely to crash the more threads you give it. You can set the PARCEL_WORKERS environment variable, which defaults to the number of cores on your machine.

[Brooooooklyn]

Released in https://github.com/napi-rs/napi-rs/releases/tag/napi%402.12.2