Repository navigation
segfault in ada::url_aggregator #49960
Description
Activity
- addedwhatwg-urlIssues and PRs related to the WHATWG URL implementation.Issues and PRs related to the WHATWG URL implementation.
on Sep 29, 2023 cc @lemire @nodejs/url
It appears that the bug is caused with this trace:
0 node 0x1016ba17c ada::unicode::has_tabs_or_newline(std::__1::basic_string_view<char, std::__1::char_traits<char>>) + 80 (ada.cpp:9841) [inlined]I've talked to @isaacs and appears that they're using M1 (NEON). We might have a bug in our SIMD solution @lemire
Ref: https://github.com/ada-url/ada/blob/main/src/unicode.cpp#L49
If it only crashes when you have a large number of processes, then it is likely not a bug in the C++ code. It is likely ressource exhaustion, and it has likely to do with Node.js/v8 stability.
If it's a segfault that would have to do with invalid memory access, not running out of memory.
If it's a segfault that would have to do with invalid memory access, not running out of memory.
If you try to allocate memory and it fails, and you have disabled exceptions in C++, you get back a null pointer. Dereferencing a null pointer is a segmentation fault.
I am not claiming that's the mechanism at play here, but we don't have a reproducible test case so one can only speculate. The only information that we have is that it only occurs if the system is highly stressed. Other possibilities include data races (outside of
ada::can_parsesinceadais single-threaded). Without a reproducible test case, it is difficult to do anything productive.Fixed upstream in ada-url/ada#519
Thanks @isaacs for the report.
Both node.js and ada need to get ARM-based sanitized testing. For ada, I opened an issue at ada-url/ada#520
For node.js, someone should check. I know it runs sanitizers, but possibly only on x64 builds.
cc @nodejs/build
Reacted by Mert Can Altin- addedconfirmed-bugIssues and PRs for confirmed bugs.Issues and PRs for confirmed bugs.
on Sep 30, 2023 Thanks!
Reacted by Yagiz Nizipli
Version
v20.7.0
Platform
Darwin moxy.lan 22.6.0 Darwin Kernel Version 22.6.0: Fri Sep 15 13:41:28 PDT 2023; root:xnu-8796.141.3.700.8~1/RELEASE_ARM64_T6000 arm64
Subsystem
url
What steps will reproduce the bug?
It's unclear, unfortunately. I'm finding this only when running quite a lot of node processes at one time, when testing all the packages in the tapjs monorepo. It is very sporadic, and only happens on node 20.
How often does it reproduce? Is there a required condition?
Sporadically
What is the expected behavior? Why is that the expected behavior?
Expect that a segfault will not happen.
This is expected because programs that don't segfault tend to be more useful 😅
What do you see instead?
Occasional segfaults.
Additional information
Here's the stack trace where the segv happens:
Stack is always the same when the fault occurs.
Full macOS ips report: https://gist.github.com/isaacs/4f313a514b3a95e6268381e957fb32fe
Happy to capture a proper core dump and share it with y'all if that's useful, but I'd rather not put the contents of my computer's memory buffer on the internet in a gist, just in to be on the safe side. Could be some sensitive stuff in process.env or something.