Closed Bug 397596 Opened 15 years ago Closed 13 years ago

100% cpu usage with binding setting position: fixed in constructor

Categories

(Core :: XBL, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: martijn.martijn, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(4 files)

Attached file testcase
See testcase, which uses 100% cpu on load with current trunk build.
It doesn't happen with a 2007-02-24 build, but does happen with a 2007-02-25 build:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-02-24+04&maxdate=2007-02-25+09&cvsroot=%2Fcvsroot
I think this is a regression of bug 366770, because I explicitly need to use the url for the binding without the fragment identifier to get the bug to appear.

This is no hang, I can still use the browser, but I had unminimized testcases that could hang the browser completely, fwiw.
The hanging testcase would be great too.

attachment 282352 [details] gets somehow into a loop where 
nsGfxScrollFrameInner::AsyncScrollPortEvent::Run gets called all the time.
AsyncScrollPortEvent is nsRunnable, so processing other events isn't blocked, 
which is why the testcase doesn't hang.
Using overflow and underflow events one could pretty easily reproduce non-hanging 100% cpu usage, I think. Just modify DOM or styling in overflow/underflow event listener so that a new event is dispatched.
But IMO that isn't actually any worse than
function foo() { setTimeout(foo, 0); } setTimeout(foo, 0);

But ofc in this case it would be better know why those bindings trigger
overflow/underflow event loop.
Some more information. Something creates new AsyncScrollPortEvents, but
those never actually do anything. So the loop is elsewhere.
(I think I can still prevent some useless AsyncScrollPortEvents, but
that is a different bug.)
(In reply to comment #1)
> The hanging testcase would be great too.

I'm afraid I don't have a small testcase for that, only the very big testcase (which is really big).
I just minimized the existing testcase further, without keeping a copy of the smallish hanging testcase.
Attached file testcase2
I'm also getting a similar thing with this testcase, this time using ::before in the binding. Again, 100% cpu using without locking up the browser, although I have an unminimized testcase that also completely locks up the browser (and eats up memory).
..and using large amounts of memory.
Attached file testcase3, zipped
Similar testcase as testcase2, but now it's hanging the browser.
Severity: normal → critical
Depends on: 507991
I can reproduce on testcase (and it is fixed by bug 507991), but not on testcase 2 or testcase 3.
Should be fixed by bug 507991.
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.