Closed
Bug 404304
Opened 17 years ago
Closed 15 years ago
importedCSS rule causes an infinite loop and crash with JSView extension installed [@ nsRuleNode::WalkRuleTree]
Categories
(Core :: CSS Parsing and Computation, defect, P5)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: wormsxulla, Unassigned)
References
()
Details
(Keywords: crash, regression)
Crash Data
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102503 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102503 SeaMonkey/2.0a1pre
Running SeaMonkey 2.0a1pre with xSidebar and the JSView extension installed:
When visiting
http://quotes.burntelectrons.org/browse
SeaMonkey CPU usage jumps to 100%, a "busy script" message is received, and SeaMonkey has to be killed to get out of it.
Here is my configuration:
My configuration below:
- - -
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007102503 SeaMonkey/2.0a1pre
extensions
Extensions(enabled: 11, disabled: 0)
http://www.mozilla.org/"APNG Edit 1.0
http://console2.mozdev.org/index.html" Console² 0.3.8+
http://www.mozilla.org/projects/inspector/" DOM Inspector 1.9a9pre
http://flashblock.mozdev.org Flashblock 1.3.7.1
http://greasemonkey.mozdev.org/" Greasemonkey 0.7.20070607.0 http://mozilla.doslash.org/infolister" InfoLister 0.9f.1
http://www.hacksrus.com/~ginda/venkman/" JavaScript Debugger0.9.87
http://forum.softwareblaze.com" JSView 1.4
http://menueditor.mozdev.org/" Menu Editor 1.2.3.3
http://wiki.mozilla.org/SeaMonkey:Debug_And_QA_UI" SeaMonkey Debug and QA UI 1.0pre
http://xsidebar.mozdev.org/" xSidebar 1.0.3
"themes"
Themes
SeaMonkey Default Theme 1.0
SeaMonkey Modern 1.0
plugins"
DivX Player Netscape Plugin
DivX® Content Upload Plugin
DivX® Web Player
Java(TM) Platform SE 6 U3
Microsoft® DRM
Mozilla Default Plug-in
RealJukebox NS Plugin
RealPlayer Version Plugin
RealPlayer(tm) G2 LiveConnect-Enabled Plug-In (32-bit)
Shockwave Flash
Windows Media Player Plug-in Dynamic Link Library
------
The website displays fine in SeaMonkey 1.1.1 with JSView installed, the creator of JSView says that this bug occured in trunk
Reproducible: Always
Steps to Reproduce:
1. Visit http://quotes.burntelectrons.org with SeaMonkey 2.0a1pre + xSidebar + JSView
2. Click "browse" in the burntelectrons.org menu
3. Wait...
Actual Results:
CPU usage jumps to 100%
A "busy script" message is displayed, but can't easily be killed.
Expected Results:
The website should display the funny Mozilla quotes ;-)
I have reported this problem in the JSView forum here:
http://forum.softwareblaze.com/viewtopic.php?t=182 - I'll copy the reply from the creator of JSView below:
"The problem is actually with the latest SeaMonkey build. To make sure that all of the imported css are retrieved the jsview extension has to enter into a unusual loop that has caused some problems with a few browsers. In fact Firefox displayed the same problem until a patch was added to fix this bug. It appears that the same bug has found it's way into the latest SM build. Unfortunately the only thing that can be done at the moment is file a bug report (if one is not already filed) at bugzilla.mozilla.org and hope that they fix it soon. I'll see if I can find the previous bug report for Firefox. I'll post the link if I can find it."
Ok, I finally found the link. This bug appeared prior to the FF2.0 release.
https://bugzilla.mozilla.org/show_bug.cgi?id=337889
Basically what's happening is that the importedCSS method is calling itself from within the same method.
cssarray.concat(this.importedCSS(rules[j].styleSheet));
Apparently in some browsers that causes an endless loop to occur. And unfortunately there's no other way to ensure that the extension has retrieved every imported stylesheet. Hopefully this should be sorted out before SM2.0 is officially released.
Code:
importedCSS: function(css) {
var j;
var cssarray = [];
var rules = css.cssRules;
for (j=0; j<rules.length; ++j) {
if (rules[j].type==3) {
cssarray.push(rules[j].styleSheet.href);
cssarray = cssarray.concat(this.importedCSS(rules[j].styleSheet));
} else { break; }
}
return cssarray;
},
So, it appears that the same problem was found and fixed on Firefox core :
https://bugzilla.mozilla.org/show_bug.cgi?id=337889
Comment 1•17 years ago
|
||
Also happens in Firefox with JSView installed, visiting the URL and clicking Browse, though I haven't seen a crash. Unresponsive script dialog comes up and after ending the script Firefox becomes responsive again.
This isn't really the same problem as bug 337889 which caused an immediate crash.
Assignee: general → nobody
Component: General → Style System (CSS)
Product: Mozilla Application Suite → Core
QA Contact: general → style-system
Comment 2•17 years ago
|
||
After clicking "Random" on the URL page and stopping the unresponsive script a few times I did crash.
http://crash-stats.mozilla.com/report/index/72c1e07a-96a9-11dc-90c2-001a4bd43ed6
str:
1) install JSView https://addons.mozilla.org/en-US/firefox/addon/2076
2) Go to http://quotes.burntelectrons.org/browse
3) Click Random
4) when the unresponsive script dialog comes up, Click Stop Script
5) Click Random again
6) At this point several unresponsive script dialogs appear and clicking Stop Script crashes Minefield
crash at nsRuleNode::WalkRuleTree
Summary: importedCSS rule causes an infinite loop and crash with JSView extension installed → importedCSS rule causes an infinite loop and crash with JSView extension installed [@ nsRuleNode::WalkRuleTree]
Comment 3•17 years ago
|
||
This is a regression since 2007100104, sorry, don't have time to narrow this down further atm.
Flags: wanted1.9+
Flags: blocking1.9?
Flags: blocking1.9-
Priority: -- → P5
Comment 4•17 years ago
|
||
I did some investigating and the recursive function isn't actually the cause of the unresponsive script dialog. The offending code is actually in the isCSSExternal method of jsview where it removes duplicates.
//check for duplicate entries and remove them
cssarray.sort();
for (var i=0; i<cssarray.length-1; ++i) {
while (cssarray[i]==cssarray[i+1]) {
cssarray.splice(i,1);
}
}
(where cssarray has been created using the importedCSS method in comment 0)
Some how cssarray has a bunch of null elements in it which end up at the end of the array after the sort operation and after removing all but one of them execution gets stuck in the while loop comparing the last element of cssarray (which is null) to a nonexistant element - the result of which is apparently true.
I don't know how cssarray ends up having null elements in it but I did find a regression range for this behaviour:
2007102304 - No Unresponsive Script Dialog
2007102407 - Dialog appears
bonsai link: http://tinyurl.com/22ajl7
What ever it is that's going on there is probably a separate bug from what is causing the crash.
As for the actual crash, I noticed during testing that the STR I gave in comment 2 aren't always reliable. Part of the problem is that a large range of events cause JSView to refresh the list of styles, and only occasionally does it get stuck in the loop I mentioned above. I did notice that builds after 2007110212 are much easier to trigger the crash with and that in current builds it's less reproducible, but it does still crash with the yesterday's nightly: bp-9bf029c7-b1d8-11dc-942a-001a4bd43ef6 .
The regression range above seems to implicate either Bug 398982 or Bug 397427 for breaking JSView but that probably just exposed the cause.
Mats, can you shed any light on this?
Keywords: qawanted
Comment 5•17 years ago
|
||
The non-crash part of this is going to be fixed in bug 405818. Not sure about the crash part.
Comment 6•17 years ago
|
||
I guess fixing the null cssarray elements in bug 405818 will prevent JSView (the old 1.5 version) from entering it's endless loop under most circumstances and sidestep the crash.
Boris, what would be needed to fix the crash independently of bug 405818? And do you think it would be worth trying to build a testcase where cssarray has two valid duplicate entries at the end - which would trigger the same endless loop but may or may not crash in the same way?
Flags: wanted1.9+ → wanted1.9-
Comment 7•15 years ago
|
||
bz, do we care about the "crash part" of this bug, or should we just close it? Sounds like debugging the crash would be a painful archeological exercise.
Comment 8•15 years ago
|
||
I think marking this incomplete should be fine.
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ nsRuleNode::WalkRuleTree]
You need to log in
before you can comment on or make changes to this bug.
Description
•