Debugger performance issue with obfuscated javascript (debugger statements in loop)
Categories
(DevTools :: Debugger, defect, P3)
Tracking
(Not tracked)
People
(Reporter: jdescottes, Unassigned)
References
(Blocks 1 open bug)
Details
Extracted from a real live example, the following test page can hang the DevTools UI when you open the toolbox: https://prevent-debugger-example.glitch.me/
The page contains a simple script which will run a debugger statement in a setTimout 100.
The "prettified" script is
(function() {
(function a() {
try {
(function b(i) {
if (("" + i / i).length !== 1 || i % 20 === 0) {
(function() {}.constructor("debugger")());
} else {
debugger;
}
b(++i);
})(0);
} catch (e) {
setTimeout(a, 100);
}
})();
})();
The HTML page simple imports the script.
STRs:
- open https://prevent-debugger-example.glitch.me/
- open devtools
- wait until the debugger UI is correctly rendered (ie shows the breakpoint etc...) and you can interact with the rest of devtools UI
ER: Should be fast, there is just one source file
AR: The performance issue can go from "taking a few seconds to open" to "fully blocking the main process indefinitely". Recording a profile seems to make it even slower, although considering that the performance is different every time I try this, it might be a red herring.
Profile performance at https://share.firefox.dev/2WCl7Qj
We seem to perform a lot of calls to addSources. Considering the breakpoint is added via (function() {}.constructor("debugger")());
, it creates a new dynamic source everytime. I assume that during the debugger startup, we must be picking up a lot of sources that way, before we settle on stopping on one of the debugger statements?
Reporter | ||
Comment 1•3 years ago
•
|
||
Note: reducing the timeout delay from 100ms to 10ms makes the issue much more visible. You can try the modified version at 10ms at https://spam-debugger-example.glitch.me/
Reporter | ||
Comment 2•3 years ago
|
||
Changing severity to S3 because performance edge case
Description
•