As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact
Last Comment Bug 691824 - Hang using latest nightly
: Hang using latest nightly
: hang, regression
Product: Core
Classification: Components
Component: Layout: R & A Pos (show other bugs)
: 10 Branch
: All All
: -- critical (vote)
: mozilla10
Assigned To: :Ehsan Akhgari
: Jet Villegas (:jet)
Depends on: 694248
Blocks: 10209
  Show dependency treegraph
Reported: 2011-10-04 10:26 PDT by Bram Speeckaert
Modified: 2015-11-01 16:18 PST (History)
7 users (show)
ehsan: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

WinDbg log (16.04 KB, application/x-zip)
2011-10-04 10:58 PDT, Alice0775 White
no flags Details
reduced html (16.73 KB, text/html)
2011-10-04 12:55 PDT, Alice0775 White
no flags Details
Patch (v1) (18.26 KB, patch)
2011-10-06 13:54 PDT, :Ehsan Akhgari
roc: review+
Details | Diff | Splinter Review

Description User image Bram Speeckaert 2011-10-04 10:26:06 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111004 Firefox/10.0a1
Build ID: 20111004030858

Steps to reproduce:

1) Open in a tab.
2) Click 'Toon' button.
3) Click 'Verklein' button, close the tab or close Firefox.

Actual results:

Firefox will hang and soak up a CPU core completely every single time.

Expected results:

The page should return to the state it was in before clicking the 'Toon' button.

The hang occurs with the latest nightly, but not with the latest Aurora build. Managed to trigger the hang consistently on:
-Windows 7 64bit using both 32 and 64bit nightlies
-Windows XP
-Ubuntu 10.10 32bit running in VirtualBox
Comment 1 User image Matthias Versen [:Matti] 2011-10-04 10:48:20 PDT
confirming with Mozilla/5.0 (Windows NT 6.1; rv:10.0a1) Gecko/20111003 Firefox/10.0a1 SeaMonkey/2.7a1

This works with FF7.0.1
Will try to find a regression range and or stack trace later
Comment 2 User image Alice0775 White 2011-10-04 10:50:33 PDT

Regression window(m-c hourly)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929122038
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1 ID:20110929141938
Comment 3 User image Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 10:52:10 PDT
My money is on Ehsan here....
Comment 4 User image Alice0775 White 2011-10-04 10:58:21 PDT
Created attachment 564607 [details]
WinDbg log
Comment 5 User image Boris Zbarsky [:bz] (still a bit busy) 2011-10-04 11:21:39 PDT
Looks like a RecreateFramesForContent leading to lots of CaptureFrameState.....  Are we just recreating over and over or something else?
Comment 6 User image Alice0775 White 2011-10-04 12:55:08 PDT
Created attachment 564647 [details]
reduced html
Comment 7 User image :Ehsan Akhgari 2011-10-06 13:54:00 PDT
Created attachment 565344 [details] [diff] [review]
Patch (v1)

This was a stupid mistake that I made.  nsTableOuterFrame::GetChildLists was returning the principal child list twice.
Comment 9 User image :Ehsan Akhgari 2011-10-06 16:26:04 PDT
This patch was effectively wallpapering over this bug... :-)

So I backed it out now that this is fixed for real:
Comment 11 User image Mozilla RelEng Bot 2011-10-07 16:08:39 PDT
Try run for 2b3b601727a6 is complete.
Detailed breakdown of the results available here:
Results (out of 193 total builds):
    exception: 2
    success: 154
    warnings: 15
    failure: 22
Builds available at
Comment 12 User image Alex Keybl [:akeybl] 2012-01-05 13:19:19 PST
Now that we have a better understanding of this bug, is it of enough concern (and the patch low enough risk) to consider for Beta 10?
Comment 13 User image Alex Keybl [:akeybl] 2012-01-05 13:20:09 PST
Sorry, missed that this was fixed on 10 already. Disregard the above.

Note You need to log in before you can comment on or make changes to this bug.