I get the following assertions on load: ###!!! ASSERTION: Weird parent in ConstructTableForeignFrame: 'parentFrame == aState.mPseudoFrames.mCellInner.mFrame', file /home/bzbarsky/mozilla/xlib/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 2982 ###!!! ASSERTION: RemovedAsPrimaryFrame called after PreDestroy: 'PR_FALSE', file /home/bzbarsky/mozilla/xlib/mozilla/layout/html/forms/src/nsTextControlFrame.cpp, line 1302 Followed by a crash due to calling GetStyleData on a deleted frame. It'd be very nice if someone could create a minimal testcase showing the crash...
Confirming crash with trunk build 2004-05-23-07 on Windows XP. Full stacktrace coming as an attachment.
Created attachment 149166 [details] Testcase for crash I stripped everything from the URL which wasn't needed to remain the crash. The testcase crashes Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040522 Firefox/0.8.0+
Created attachment 149167 [details] Another small crash testcase, a little smaller Well, maybe not very necessary anymore, but since I was busy with it, and it is a bit smaller than the other crash testcase I decided to upload it anyway. Crashes for me with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a1) Gecko/20040520 Firefox/0.8.0+
also crashes windows 1.7rc2 : TB57883G
Actually, could someone grab the JS files too and see whether you can remove anything from those? And whether you can inline them, for that matter? It looks like the second JS file is somehow triggering a bug in our frame construction code that makes everything else break. Note that the exact crash location will sorta depend on when you end up first referencing deleted memory, so the signature in the summary is likely not the only one this bug will show...
Hermann, see comment 7. We know where and sorta why this crashes; what's not clear is what triggers the bogus frame construction.
Created attachment 149213 [details] 700 byte zipped testcase, local unzip into a folder in your harddisk. 244454.html, 1f.js, 2f.js are created, each about 200 byte. start 244454.html, enjoy crash ;-)
TB59179H http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB59179H DoDeletingFrameSubtree 585be954 Access violation c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp, line 9103 js files can even be more reduced: var ba = ''; ba += '<'+'div style="position: absolute; left: 0px; top: 0px;"><'+'/div>'; document.write(ba); var ba = ''; ba += '<'+'table width="130"><'+'tr><'+'td><'+'/td><'+'/tr><'+'/table>'; document.write(ba);
In fact, you could even get rid of the intermediary variables in the JS files altogether. Also, does it matter whether you document.write a <script> or just document.write the div or table in the original HTML? That's the part I'm really interested in.... (and attach the result as an attachment, instead of pasting stuff into the bug). Also, it's not worth it to post stacks and talkback ids. See comment 7. They're just noise.
Created attachment 149252 [details] no crash testcase with position:relative I further removed unneeded things from Hermann's code and encountered something perhaps interesting. With position:absolute and position:fixed the testcase leads to a crash, but with position:relative nothing happens.
(In reply to comment #13) document.write without a <script> and a extern .js file as src doesn't crash.
Created attachment 149288 [details] Minimal-ish testcase This inlines all the scripts (using data: URIs; just putting them directly inline doesn't work), removes the <a> and <blink> in favor of <span>, and replaces <center> with <div>. It looks like the two nested ib splits, the residual style, and the document.written external scripts are necessary... I'll try to look into this tomorrow afternoon/evening.
bz, does it look like it might be a straight forward fix, or complicated?
Hard to tell. We're crashing under DoDeletingFrameSubtree because the outOfFlowFrame we get is already destroyed, so we die when calling GetStyleData on it. Earlier up, we seem to have a <span> as a float containing block, so things are already pretty broken at that point...
Note that I tried to wallpaper over this by adding: ((nsPlaceholderFrame*)childFrame)->SetOutOfFlowFrame(nsnull); when we enqueue the out-of-flow frame for destruction in DoDeletingFrameSubtree, but we still crash. Also note that my stack is not under ReflowFloat -- I crash under WipeContainingBlock, called from ContentAppended, etc, when appending to the <font>. The multiple IB splits here suck. :(
Marking blocking1.7+, although this is at risk for being minused, since we're hoping to ship early next week.
Created attachment 150169 [details] stack with some comments This is a stack from the crash in attachment 149288 [details], with some additional comments based on examining some frames in the debugger. I think the cause of the problem is that WipeContainingBlock is being asked to wipe an inline rather than a block (frame 20). Does that make sense?
What's happening is that in ContentAppended, |containingBlock| is the anonymous block for the inline element that already contains a block. When we call |ContentReplaced|, that's the inline, so we end up going back another level. I think the fix involves making sure to walk up further if we have a :-moz-anonymous-block.
I think any fix here will be too risky for the branch at this point. This crash is just on one site, as far as we know.
Created attachment 150223 [details] [diff] [review] patch
Fix checked in to trunk, 2004-06-17 11:51 -0700.
Verified FIXED with build 2004-06-30-08 on Windows XP.
*** Bug 271338 has been marked as a duplicate of this bug. ***