New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extremely slow assertion error message generation for minified bundles #52677
Comments
@nodejs/assert @nodejs/performance |
Erm... How do you |
Can you create a reproduction of the problem without using AWS Lambda? We need something we can run locally. |
https://gist.github.com/martinjlowm/aa7d02905f7c49935be0a3bf4819a5f3
works well as a regression. Without having explored the stack frame fully - I believe it's the same effect as we experience in (some of) our bundles. |
What a file. My vscode and even gedit is crashing going nuts... Is it really only related when requiring assert. It feels like this is more an issue in acorn trying to make sense of the semicolons. |
Hehe - well, I suppose it's good to benchmark against. From the bundle I was originally testing (from the attached screenshot), the assert module was repeatedly proceeding to |
Nice catching that one! Seems like not all measures to prevent this are working as expected. I will try to look into it soon (next two-three days). If someone else wants to look into it, please go ahead! |
Version
v20.11.1
Platform
Darwin wololobook 23.4.0 Darwin Kernel Version 23.4.0: Fri Mar 15 00:11:05 PDT 2024; root:xnu-10063.101.17~1/RELEASE_X86_64 x86_64 i386 Darwin
Subsystem
assert
What steps will reproduce the bug?
;
'srequire('node:assert')(null)
getErrMessage
, specificallyfindColumn
feeding intoacorn
takes several minutesHow often does it reproduce? Is there a required condition?
We've experienced this in production a number of times but we were never able to figure out what the problem was. We ship minified code to AWS Lambda and utilize the
assert
module for, well, runtime assertions. We were seeing unexplainable timeouts whenever a falsy case was hit.It was luck that we found this in our test suite because we ran it through Terser by mistake.
What is the expected behavior? Why is that the expected behavior?
I'd expect the column search to be much faster, closer to something in the sub second/milliseconds range.
What do you see instead?
It takes minutes to construct the assertion error message.
It looks like a subset of the code may be passed to
acorn
(https://github.com/nodejs/node/blob/main/lib/assert.js#L232) leading to syntax errors as it parses till the end (https://github.com/nodejs/node/blob/main/lib/assert.js#L265),acorn
then reports that error whenever it hits that point (https://github.com/nodejs/node/blob/main/lib/assert.js#L278),findColumn
then continues to the next token and reads more chunks if necessary andacorn
starts from scratch.A bundler like Webpack emits an IIFE which itself contains an immediate block. I believe that is the majority of time spent for
acorn
traversing each token in it. I suspect the many errors come from that very block that is incomplete, soacorn
wastes time trying to parse something that is known to be incomplete.I think a better regression to the reproduction section is to do an IIFE and drop semi colons in there:. Interestingly enough, an IIFE around it is not affected by it.(() => {;;;;;;;...;;;;;;require('node:assert')(null);})()
Another interesting thing is that this does not affect normal Error's - is there a particular reason why they run on two different implementations?
Additional information
The text was updated successfully, but these errors were encountered: