`new Intl.Segmenter().segment()` causes SEGFAULT with `--with-intl=small-icu` and no runtime ICU data
@srl295 is already working on this.
Since Mar 10, 2024.
- Dominant language
- JavaScript
- Stars
- 122k
- Forks
- 37.3k
- Avg merge
- 4d 2h
- Merged PRs (30d)
- 283
Description
Version
v20.10.0
Platform
Linux acfbcf435a24 6.7.4-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Feb 5 22:21:14 UTC 2024 x86_64 GNU/Linux
Subsystem
Intl
What steps will reproduce the bug?
- Obtain a nodejs build compiled with
--with-intl=small-icu.* - Execute
new Intl.Segmenter().segment()in the REPL.
*In my case that was the nodejs package from Fedora 39 without nodejs-full-i18n. This can be obtained as follows:
- Create a docker/podman container with Fedora 39:
podman run --rm -it fedora:39 dnf install -y --setopt=install_weak_deps=False nodejs
How often does it reproduce? Is there a required condition?
Always, as long as no runtime ICU data is present.
What is the expected behavior? Why is that the expected behavior?
NodeJS should fallback to a locale-unaware string separator, not provide Intl.Segmenter at all, or raise a JS exception.
The status quo offers no possibility to know if segmentation is safe and calling it results in a segmentation fault and therefore instant termination of the process.
What do you see instead?
A segmentation fault
Additional information
Backtrace
Core was generated by `node'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 v8::internal::JSSegments::Create () at ../../deps/v8/src/objects/js-segments.cc:33
33 segmenter->icu_break_iterator().raw()->clone();
[Current thread is 1 (Thread 0x7f0039bc7c40 (LWP 49))]
(gdb) bt
#0 v8::internal::JSSegments::Create () at ../../deps/v8/src/objects/js-segments.cc:33
#1 0x00007f003c910b24 in Builtin_Impl_SegmenterPrototypeSegment () at ../../deps/v8/src/builtins/builtins-intl.cc:1170
#2 v8::internal::Builtin_SegmenterPrototypeSegment () at ../../deps/v8/src/builtins/builtins-intl.cc:1160
#3 0x00007f003c755df6 in Builtins_CEntry_Return1_ArgvOnStack_BuiltinExit () from /lib64/libnode.so.115
#4 0x00007f003c6c7d1c in Builtins_InterpreterEntryTrampoline () from /lib64/libnode.so.115
#5 0x0000167f10a804e9 in ?? ()
#6 0x000003439a820159 in ?? ()
#7 0x0000000500000000 in ?? ()
#8 0x0000167f10a805b9 in ?? ()
#9 0x000027cb1169d0c9 in ?? ()
#10 0x000027cb1169d0c9 in ?? ()
#11 0x000003439a820159 in ?? ()
#12 0x0000167f10a804e9 in ?? ()
#13 0x0000004900000000 in ?? ()
#14 0x000000e7305257a1 in ?? ()
#15 0x0000000000000002 in ?? ()
#16 0x000000e730525f49 in ?? ()
#17 0x000003439a80ef49 in ?? ()
#18 0x00007ffefb915ea8 in ?? ()
#19 0x00007f003c6c60dc in Builtins_JSEntryTrampoline () from /lib64/libnode.so.115
#20 0x000003439a80eee1 in ?? ()
#21 0x000027cb1169c439 in ?? ()
#22 0x000000e730525f49 in ?? ()
#23 0x000000000000002c in ?? ()
#24 0x00007ffefb915f10 in ?? ()
#25 0x00007f003c6c5e03 in Builtins_JSEntry () from /lib64/libnode.so.115
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
On a Fedora 39 system one should be able to open the coredump with:
DEBUGINFOD_URLS=https://debuginfod.fedoraproject.org/ gdb /usr/bin/node-20 coredump
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.