Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051203 Firefox/1.6a1 Steps to reproduce: 1. Go to http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html and click "Deny" (otherwise the testcase will give you same-origin dialogs). 2. Download and unzip the testcase. 3. Load the testcase. 4. Wait for the testcase to load, then wait 4 seconds, then wait for it to run. Result: the status bar counter only gets to 1983, not 2300, and now you can't click on some things in the page or browser UI. 5. Close the window. Result: Firefox.exe process is still running. I found this bug while running randomstyles on a saved copy of aol.com. The testcase is not reduced, but it is de-randomized, so it might be possible to reduce. The last time I tried to reduce a random styles / stuck process testcase based on aol.com, I didn't get far. In a debug build, I see the following assertion failure during when I close the window: ###!!! ASSERTION: post-reflow queues not empty. This means we're leaking: 'mFirstDOMEventRequest == nsnull && mLastDOMEventRequest == nsnull && mFirstAttributeRequest == nsnull && mLastAttributeRequest == nsnull && mFirstCallbackEventRequest == nsnull && mLastCallbackEventRequest == nsnull', file c:/buildmoz/mozilla/layout/base/nsPresShell.cpp, line 1601 These crashes might be related: TB12655310W, TB12654632M.

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051209 Firefox/1.6a1. Argh.

I think this bug is fragile enough that: (1) it's really hard to reduce a "recorded" testcase. (2) any non-reduced "recorded" testcase isn't likely to still cause the hang in a build from next week, or even in a debug build made the same day (if found using a release build). Luckily (?), the bug can almost always be reproduced by running the Random Styles bookmarklet on this page (derived from http://www.aol.com/). For example, with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051209 Firefox/1.6a1: 1, 0, 100, 100 -> stops at 3400, half-hang and fails to exit 2, 0, 100, 100 -> stops at 3300, half-hang and fails to exit 3, 0, 100, 100 -> stops at 1700, half-hang and fails to exit

I don't think I'm going to be able to reduce a testcase for this bug. Can you guys reproduce the bug? Are you likely to figure out how to fix it without a reduced testcase?

The last line in the console when this happens is always "--WEBSHELL [address] == 2".

So I assume part of the steps to reproduce is to paste the bookmarklet from bug 306939 into the testcase? I don't see anything happening unless I do that...

Well, I somehow manage to crash with a deleted frame that is the ancestor of a quite nicely not-deleted placeholder... This happens after some firing of the assert at the end of GetChildListNameFor(), but there are so many asserts on this testcase that I don't see a sane way of just breaking for the one I want. :(

Comment 6 is correct. Regarding comment 7, I'll try to make reduced testcases for some of the assertions I hit here.

That would be nice, yeah. Perhaps even as bugs blocking this one?

bz, want to start with bug 302260, "update-band called late: 'psd->mX == psd->mLeftEdge'"? Are there other assertions from the last attachment that you especially want testcases for?

Could use testcase for the following: 13 ###!!! ASSERTION: RemovedAsPrimaryFrame called after PreDestroy: 'PR_FALSE', file /Users/admin/trunk/mozilla/layout/forms/nsTextControlFrame.cpp, line 1437 9 ###!!! ASSERTION: overflow list is not empty for initial reflow: '!overflowFrames', file /Users/admin/trunk/mozilla/layout/generic/nsInlineFrame.cpp, line 375 9 ###!!! ASSERTION: not in child list: 'nsFrameList(aChildFrame->GetParent()->GetFirstChild(listName)) .ContainsFrame(aChildFrame)', file /Users/admin/trunk/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 1882 1 ###!!! ASSERTION: node in map twice: 'Not Reached', file /Users/admin/trunk/mozilla/layout/base/nsFrameManager.cpp, line 1633 1 ###!!! ASSERTION: Could not find an adaptor!: 'Error', file /Users/admin/trunk/mozilla/layout/xul/base/src/nsBoxFrame.cpp, line 679 1 ###!!! ASSERTION: Allowed only one anonymous view between frames: 'ancestorView == view->GetParent()->GetParent()', file /Users/admin/trunk/mozilla/layout/generic/nsContainerFrame.cpp, line 416

Bug 321894 has a testcase that triggers the "RemovedAsPrimaryFrame called after PreDestroy" assertion.

No sign of a fix, not realistic for 1.8.0.1

Bug 322786 has a testcase that triggers the "Could not find an adaptor!" assertion.

BZ- Was there anything particular you were looking for when you added qawanted? bclary- please provide the qawanted support for this one.

I was fishing for a smallish reduced testcase, if one is possible.

mid-air: (In reply to comment #17) > BZ- Was there anything particular you were looking for when you added qawanted? > > bclary- please provide the qawanted support for this one. > He probably wanted a reduced testcase, but if Jesse say's he can't create one then that is probably the case. I tested all three scenarios in comment 3 on a winxp trunk debug build from 2006-02-11 and did not crash or hang after running randomstyles up to 20,000 although there are several "very bad" assertions. I do hang in a winxp 2006-02-11 1.8 debug build, but 1.8 does not have a number of the fuzz related fixes that have gone on the trunk. I say move this bug to trunk and mark it as wfm.

I'll try to reproduce on trunk when I have access to my Windows machine again (in about a week), and mark this bug as WFM if I can't. I still owe bz reduced testcases for several assertions in comment 13. I'll try to make those over the next few weeks, after I find or create a delta debugging tool to do the tedious parts of testcase reduction.

Testing with trunk nightlies on Windows and Mac, I'm still getting various crashes and drawing issues when running Random Styles on the saved copy of aol.com. Unfortunately, none of them are reproducible :( bz, want to try fixing the three assertions we have small testcases for (bug 302260, bug 321894, bug 322436) so we can see if that helps? Is the removal of BuildFloatList (bug 282173, which this bug depends on indirectly) likely to help?

Removing BuildFloatList will fix a whole class of bugs where we lose track of frames and fail to tear them down properly, yes. I'll look at the three bugs you mention and see what I can figure out.

Most of the assertions and warnings seem to be gone now. Now I only get: 840 ###!!! ASSERTION: update-band called late: 'psd->mX == psd->mLeftEdge', file /Users/admin/trunk/mozilla/layout/generic/nsLineLayout.cpp, line 389 64 WARNING: nsBlockFrame::CheckFloats: Explicit float list is out of sync with float cache: file /Users/admin/trunk/mozilla/layout/generic/nsBlockFrame.cpp, line 7068 10 WARNING: aFrame is already associated with a region: file /Users/admin/trunk/mozilla/layout/generic/nsSpaceManager.cpp, line 818 10 ###!!! ASSERTION: bad float placement: 'NS_SUCCEEDED(rv)', file /Users/admin/trunk/mozilla/layout/generic/nsBlockReflowState.cpp, line 1011

On WinXP: I'm not seeing the "stuck process" issue any more (tested with 2006-04-10 trunk nightly). But even with a 2006-04-08 build (before BuildFloatList removal), I only managed to reproduce that issue in 1 in 5 tries, so it's hard to be sure it's gone. On Mac: It stops painting often, and I got a hang once. (Other fuzz bugs where Firefox on Mac stops painting: bug 305029, bug 311478, bug 322731.) I'm marking this bug report as WFM because I don't think it's useful (any more?). Testing elsewhere is more likely to result in the creation of reduced testcases for any heisenbugs that remain here. (P.S. Lithium is great for reducing bugs like "random styles on this url with these parameters causes a crash 20% of the time".) bz, tell me if you especially want reduced testcases for the "bad float placement" assertion or the "aFrame is already associated with a region" warning.

I've never seen those before, so I'm not sure what they mean in terms of us needing to worry... roc, do you know?

It means we reflowed the float twice without rewinding the space manager, and it's not clear why. I assume that if it was in the frame tree twice, we'd have crashed on a double destroy, and it appears that's not happening. So I don't know what's happening, but if we're not crashing, then I have no reason to believe there's an exploitable security issue.

Ok, sounds like a minimal testcase really would help then... (let us figure out what's happening, maybe).

Bug 317278 and bug 321896 both have small testcases for that assertion/warning pair.