Segfault on non-x86_64 architectures

[jamesjer]

Version

v20.12.2

Platform

Linux f0d1a0d0bda34bd79ec4cf6a39b52071 6.7.7-200.fc39.aarch64 #1 SMP PREEMPT_DYNAMIC Fri Mar 1 17:20:07 UTC 2024 aarch64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

I do not know how to reproduce without installing third-party dependencies. On aarch64, ppc64le, and s390x Fedora Rawhide builders (but NOT x86_64), these steps always lead to a segfault:

• Install jupyterlab (with sudo dnf install jupyterlab on Fedora)
• wget https://github.com/mwouts/jupytext/archive/v1.16.1/jupytext-1.16.1.tar.gz
• tar xf jupytext-1.16.1.tar.gz
• cd jupytext-1.16.1/jupyterlab
• jlpm install

How often does it reproduce? Is there a required condition?

Those steps lead to a segfault every time on the 3 architectures indicated.

What is the expected behavior? Why is that the expected behavior?

Packages should be installed instead of segfaulting.

What do you see instead?

➤ YN0065: Yarn will periodically gather anonymous telemetry: https://yarnpkg.com/advanced/telemetry
➤ YN0065: Run yarn config set --home enableTelemetry 0 to disable

➤ YN0000: ┌ Resolution step
➤ YN0002: │ @jupyterlab/galata@npm:5.0.8 doesn't provide react (p4cf78), requested by @jupyterlab/settingregistry
➤ YN0002: │ @jupyterlab/services@npm:7.0.8 doesn't provide react (p38eec), requested by @jupyterlab/settingregistry
➤ YN0002: │ @lerna/legacy-package-management@npm:6.6.2 doesn't provide nx (pa803c), requested by @nrwl/devkit
➤ YN0002: │ jupyterlab-jupytext@workspace:packages/jupyterlab-jupytext-extension doesn't provide react (pca723), requested by @jupyterlab/settingregistry
➤ YN0002: │ jupyterlab-rise@npm:0.41.0 doesn't provide react (p4a7ca), requested by @jupyterlab/settingregistry
➤ YN0000: │ Some peer dependencies are incorrectly met; run yarn explain peer-requirements <hash> for details, where <hash> is the six-letter p-prefixed code
➤ YN0000: └ Completed in 0s 540ms
➤ YN0000: ┌ Fetch step
Segmentation fault (core dumped)

Additional information

This looks very similar to #45283.

GDB output from an aarch64 machine:

Thread 1 "node" received signal SIGSEGV, Segmentation fault.
0x0000fffff682d498 in v8::internal::JSSegments::Create (isolate=isolate@entry=0xaaaaaab6d080, 
    segmenter=segmenter@entry=..., string=...) at ../../deps/v8/src/objects/js-segments.cc:33
33	      segmenter->icu_break_iterator().raw()->clone();
(gdb) bt
#0  0x0000fffff682d498 in v8::internal::JSSegments::Create (isolate=isolate@entry=0xaaaaaab6d080, 
    segmenter=segmenter@entry=..., string=...) at ../../deps/v8/src/objects/js-segments.cc:33
#1  0x0000fffff63d2450 in v8::internal::Builtin_Impl_SegmenterPrototypeSegment (args=..., isolate=0xaaaaaab6d080)
    at ../../deps/v8/src/builtins/builtins-intl.cc:1170
#2  v8::internal::Builtin_SegmenterPrototypeSegment (args_length=<optimized out>, args_object=<optimized out>, 
    isolate=0xaaaaaab6d080) at ../../deps/v8/src/builtins/builtins-intl.cc:1160
#3  0x0000fffff6206964 in Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit () from /lib64/libnode.so.115
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) print segmenter
$1 = {<v8::internal::HandleBase> = {location_ = 0xffffffff89e0}, <No data fields>}
(gdb) print *(JSSegmenter *)0xffffffff89e0
$2 = {<v8::internal::TorqueGeneratedJSSegmenter<v8::internal::JSSegmenter, v8::internal::JSObject>> = {<v8::internal::JSObject> = {<v8::internal::TorqueGeneratedJSObject<v8::internal::JSObject, v8::internal::JSReceiver>> = {<v8::internal::JSReceiver> = {<v8::internal::TorqueGeneratedJSReceiver<v8::internal::JSReceiver, v8::internal::HeapObject>> = {<v8::internal::HeapObject> = {<v8::internal::Object> = {<v8::internal::TaggedImpl<(v8::internal::HeapObjectReferenceType)1, unsigned long>> = {static kCanBeWeak = false, ptr_ = 56352163865257}, 
                static kHeaderSize = 0}, <No data fields>}, <No data fields>}, 
          static kHashMask = 2147482624}, <No data fields>}, static kMinAddedElementsCapacity = 16, 
      static kMaxElementCount = 4294967295, static kMaxElementIndex = 4294967294, static kMaxGap = 1024, 
      static kMaxUncheckedFastElementsLength = 5000, static kMaxUncheckedOldFastElementsLength = 500, 
      static kInitialGlobalObjectUnusedPropertiesCount = 4, static kMaxInstanceSize = 2040, 
      static kMapCacheSize = 128, static kFieldsAdded = 3, static kMaxInObjectProperties = 252, 
      static kMaxFirstInobjectPropertyOffset = 127, 
      static kMaxEmbedderFields = 12}, <No data fields>}, <No data fields>}
(gdb) call segmenter->icu_break_iterator()
Attempt to take address of value not located in memory.

[jamesjer]

Correction: this crash only happens on aarch64. Failures on other architectures turned out to have different causes.

Also, by default the Fedora builders operate in an ASCII environment; i.e., LC_ALL=C. I discovered today that changing the environment to C.UTF-8 makes the segfault stop happening. If a Unicode environment is required, then a failure is okay, but it should be a failure with a message indicating the problem, not a segfault.

[richardlau]

Suspect this is similar to/related to #51752.

[sgallagher]

For those coming here and seeing this on Fedora: we determined in the Fedora bug that the problem can at least be worked around by installing the nodejs-full-i18n package.

It's definitely the same issue as #51752 .

[septatrix]

Yeah this is something every Fedora user runs into if they install disable weak dependencies --setopt=install_weak_deps=False when installing node. This is quite bad...