igorshubovych
markdownlint 0.47.0 segfaults with nodejs 22
The latest version causes a regression with parsing tables, even the simplest ones:
cat <<EOF > repr.md
| title |
| ----- |
| y |
EOF
markdownlint repr.md
causes a segfault.
This happens with node v22.20.0 , the default node rpm in Fedora 43, on x86_64.
gdb doesn't have too much to say, though:
Thread 1 "node" received signal SIGSEGV, Segmentation fault.
Downloading source file /usr/src/debug/nodejs22-22.20.0-1.fc43.x86_64/out/Release/../../deps/v8/src/objects/js-segments.cc
v8::internal::JSSegments::Create () at ../../deps/v8/src/objects/js-segments.cc:33
33 segmenter->icu_break_iterator()->raw()->clone();
(gdb) bt
#0 v8::internal::JSSegments::Create () at ../../deps/v8/src/objects/js-segments.cc:33
#1 0x00007ffff5565e3d in Builtin_Impl_SegmenterPrototypeSegment () at ../../deps/v8/src/builtins/builtins-intl.cc:1235
#2 v8::internal::Builtin_SegmenterPrototypeSegment () at ../../deps/v8/src/builtins/builtins-intl.cc:1225
I tested this with nodejs24-1:24.9.0-1.fc43.x86_64 and that works fine:
node-24 /usr/local/lib/n^Ce_modules/markdownlint-cli/markdownlint.js repr.md
Also confirmed on our full project with lots of big markdown files.
So this is probably not actionable by you directly, other than avoiding the situation. If you don't care about node 22, then feel free to just close this (this is mostly due diligence in case you do care).
Thank you for reporting this!
I am alarmed at how simple your reproduction is, so I wonder if the specifics of your platform have anything to do with this. Note that CI for this project runs on a matrix of 3 OSes and Node versions 20, 22 and 24. I don't think I've seen a crash in CI for this project or for CLI2 which uses the same underlying library.
https://github.com/igorshubovych/markdownlint-cli/actions/runs/20123610055
You report this occurs in the latest version which I assume means 47 and not 46. That's significant because there is a new rule for tables in 46 that only had slight edits in 47. However, a significant change that arrived in 47 was the addition of the https://www.npmjs.com/package/string-width library. This was done to handle CJK characters better and one of the things it includes is a regular expression that matches by Unicode character class in the newer "v" mode for Unicode sets. Notably, this code does not run if there are no tables present.
I'm guessing the Node implementation is flawed in older versions in a way that crashes native code on some platforms/architectures. As you say, it's not clear what I can do about this, but I will leave it open for tracking and awareness.
Thank you again and I'm glad you found a solution!
Looking a little closer at the gdb output, the presence of "intl" and "segments" aligns with my theory above: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Segmenter/Segmenter
The string-width library is widely used, but that's no guarantee they've seen this. A quick scan of their issues didn't turn anything up and I'm not ready to search Node issues just yet. :)
You report this occurs in the latest version which I assume means 47 and not 46.
Sorry, forgot to mention that. Versions ≤ 0.46.0 were okay. This started crashing two days ago when updating to 0.47.0. This matches up pretty well with the introduction of string-width, especially "Notably, this code does not run if there are no tables present.". As that is also JS, I suppose that just triggers a bug in nodejs somewhere, and it sounds like this might be specific to Fedora.
Not digging into this further -- perhaps it serves as search engine hit with "use 24, Luke!" as a hint for some poor soul 😁