`new Intl.Segmenter().segment()` causes SEGFAULT with `--with-intl=small-icu` and no runtime ICU data
@srl295 已经在做这个了。
开始于 2024年3月10日。
- 主要语言
- JavaScript
- 星标
- 122k
- 派生
- 37.4k
- 平均合并
- 4 天 3 小时
- 30 天内合并 PR
- 272
描述
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
贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
评估
这个 Issue 还没有评估数据。