Reproducible segfaults

[danieltroger]

🐛 bug report

parcel serve segfaults, probably because my .parcel-cache is from a future version.

It is reproducible (happens every time).

Please tell me how to debug it.

🤔 Expected Behavior

No segfault

😯 Current Behavior

I tried running it with lldb as @mischnic suggested previously but I must be doing something wrong because it isn't helpful at all?????

daniel@Daniels-MacBook-Pro hatstore % lldb -- node /usr/local/bin/npm run serve
(lldb) target create "node"
Current executable set to 'node' (x86_64).
(lldb) settings set -- target.run-args  "/usr/local/bin/npm" "run" "serve"
(lldb) run
Process 25954 launched: '/usr/local/bin/node' (x86_64)

[...]

ℹ️ Server running at http://localhost:1234
⠦ Building [file].ts...
PID 25967 received SIGSEGV for address: 0x9fb17e04
0   segfault-handler.node               0x000000010485dfb0 _ZL16segfault_handleriP9__siginfoPv + 304
1   libsystem_platform.dylib            0x00007fff6fb665fd _sigtramp + 29
2   ???                                 0x0000000000000298 0x0 + 664
3   node.napi.glibc.node                0x0000000140d04833 _ZN16SourceMapBinding17addBufferMappingsERKN4Napi12CallbackInfoE + 537
4   node.napi.glibc.node                0x0000000140d09922 _ZN4Napi12InstanceWrapI16SourceMapBindingE33InstanceVoidMethodCallbackWrapperEP10napi_env__P20napi_callback_info__ + 174
5   node.napi.glibc.node                0x0000000140d0989a _ZN4Napi12InstanceWrapI16SourceMapBindingE33InstanceVoidMethodCallbackWrapperEP10napi_env__P20napi_callback_info__ + 38
6   node                                0x00000001000848ad _ZN6v8impl12_GLOBAL__N_123FunctionCallbackWrapper6InvokeERKN2v820FunctionCallbackInfoINS2_5ValueEEE + 119
7   node                                0x0000000100248c9a _ZN2v88internal25FunctionCallbackArguments4CallENS0_15CallHandlerInfoE + 520
8   node                                0x0000000100248368 _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE + 769
9   node                                0x0000000100247a3f _ZN2v88internalL26Builtin_Impl_HandleApiCallENS0_16BuiltinArgumentsEPNS0_7IsolateE + 246
10  node                                0x0000000100872839 Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 57
./build_scripts/serve: line 5: 25967 Segmentation fault: 11  ./build_scripts/parcel serve --port 1234 --target dev --no-cache --no-hmr --dist-dir dev_dist/$(basename $tenant_wd) $infile
Process 25954 exited with status = 139 (0x0000008b) 
(lldb) 

💁 Possible Solution

Fix it / tell me how to fix it

🔦 Context

Downgraded from I think 669 to 650 because 669 still isn't ready.

🌍 Your Environment

Software	Version(s)
Parcel	2.0.0-nightly.650+dc79abcd
Node	v16.1.0
npm/Yarn	npm v7.11.2
Operating System	macOS 10.15.7 (19H1030)

[danieltroger]

Ah I figured out what I was doing wrong, lldb was not attached to the process crashing. Here we go:

(lldb) run
Process 27792 launched: '/usr/local/bin/node' (x86_64)
ℹ️ Server running at http://localhost:1234
⠹ Building config.ts...
Process 27792 stopped
* thread #12, stop reason = EXC_BAD_ACCESS (code=1, address=0x9eb52204)
    frame #0: 0x000000013852f7ac node.napi.glibc.node`MappingContainer::addBufferMappings(void const*, int, int) + 64
node.napi.glibc.node`MappingContainer::addBufferMappings:
->  0x13852f7ac <+64>: cmpw   $0x7, (%rcx)
    0x13852f7b0 <+68>: movq   %rsi, -0xc8(%rbp)
    0x13852f7b7 <+75>: movq   %rdi, -0xc0(%rbp)
    0x13852f7be <+82>: jb     0x13852f7d8               ; <+108>
Target 0: (node) stopped.
(lldb) 

what do I do now?

[mischnic]

669 still isn't ready.

That nightly uses a complete rewrite of the native sourcemap package. So trying to debug a older nightly now doesn't really make sense

[danieltroger]

Nooooooo, and I finally was able to reproduce a segfault 😭😡

[danieltroger]

But what if it still could happen on 669?

[mischnic]

The previous version was written in C++, then new one in Rust. I think it's less likely to run into segfaults in the new one 😄

[danieltroger]

Hm ok. So it's not node that's segfaulting?

However I have a problem because 669 has fucked private class fields (#6289 isn't merged yet, nightly hasn't build yet) and it transpiles optional chaining even tho it shouldn't. So I can't use 669. But now for some reason, even after removing .parcel-cache 650 always segfaults.

I hope it's not due to my code and cloning my repo freshly will help…

[danieltroger]

I hope it's not due to my code and cloning my repo freshly will help…

It doesn't help 😖 I keep getting the segfault

[danieltroger]

Seems like the problem is that some dependencies got updated and versions incompatible to 650 got installed. I found an old copy of my repo where npm install has been ran and don't get any segfaults.

[mischnic]

So it's not node that's segfaulting?

No. It's a native Node module:

frame #0: 0x000000013852f7ac node.napi.glibc.node`MappingContainer::addBufferMappings(void const*, int, int) + 64

is https://github.com/parcel-bundler/source-map/blob/630a23d3e6c6a9c211f1d30821a65fbdb3b71acb/src/MappingContainer.cpp#L422

[danieltroger]

Ah, interesting. Well, let's hope all segfaults are gone with rust then.

[DeMoorJasper]

That particular segfault is definitely fixed now with the rust rewrite

[danieltroger]

Pinning @parcel/babel-plugin-transform-runtime to 2.0.0-nightly.2260 and @parcel/babel-preset-env to2.0.0-nightly.638 solved the issue.

Looking forward to bug and segfault free SWC parcel!

[danieltroger]

Nevermind, it still happens. It depends on the thing I build. But whatever.

[danieltroger]

After pinning some more things it seems to work:

-    "@parcel/optimizer-cssnano": "nightly",
+    "@parcel/optimizer-cssnano": "2.0.0-nightly.638",
-    "@parcel/packager-css": "nightly",
+    "@parcel/packager-css": "2.0.0-nightly.638",
-    "@parcel/transformer-css": "nightly",
+    "@parcel/transformer-css": "2.0.0-nightly.638",
-    "@parcel/transformer-postcss": "nightly",
+    "@parcel/transformer-postcss": "2.0.0-nightly.638+ff1a55e8",
-    "@parcel/transformer-sass": "nightly",
+    "@parcel/transformer-sass": "2.0.0-nightly.638",