Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1 Testcase usually crashes while the status bar counter says "2500". Filed as security-sensitive becasue the testcase includes code from bug 306939.

Hmm... I can't seem to reproduce a crash here (been running that testcase for about 10 mins now).

That's with a Linux trunk MOZ_CO_DATE="Fri Sep 2 22:10:00 CDT 2005" build.

Still crashes at "2500" for me. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050905 Firefox/1.6a1

Still crashes on Mac. No crash on Windows - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050908 Firefox/1.6a1

Doesn't crash for me in a debug build on Mac. I see and hear hundreds of assertion failures, though.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050923 Firefox/1.6a1 Still crashes [@ IncrementalReflow::AddCommand].

On Windows XP: WFM with today's trunk, still crashes with today's Gecko1.8 branch.

Scratch that. Trunk sometimes crashes, sometimes stops painting and fails to exit properly, and sometimes survives. I've seen similar patterns in bug 307809, so I'm hoping it's the same bug and making this bug depend on bug 307809.

On second thought, I don't think this is the same as bug 307809. I'm working on a reduced testcase for this bug now.

I think this testcase is for the same bug ;) This testcase crashes 40% of the time with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051005 Firefox/1.6a1. If it doesn't crash, try reloading a few times. When this testcase crashes, it always crashes at IncrementalReflow::AddCommand. I also saw exploitable-looking crashes at nsCSSFrameConstructor::ContentRemoved while reducing the testcase.

So... I can't reproduce the crash here. One issue I do see is that we're "losing" the popup frame -- the placeholder points to it, but the popup frame itself is not in the tree. Should probably fix that...

bz, I'm guessing you're testing on Linux, which could be the reason I see the crash and you don't. I'd be happy to test a patch and tell you whether it makes the crash go away.

Yeah, I'm on Linux. Try this, see what happens?

I think that patch fixes the crash. I'm not able to reproduce the crash in other builds as reliably as I was yesterday, though, so it's hard for me to be sure.

But now I get an infinite-recursion crash (with nsViewManager::UpdateWidgetArea being the bulk of the stack) at the original testcase while the status bar counter says 1900 or 2000. Tell me if you want a reduced testcase for that crash all I'll try to make one.

Might not be a bad idea (with a separate bug) -- I can't reproduce that crash on the "testcase (not reduced)" testcase.

Filed bug 311457 for the crash mentioned in comment 18.

Comment on attachment 198717 [details] [diff] [review] Something to try roc, this just makes us handle the case of people using XUL non-menu popups in a document without a root XUL box gracefully (without losing frames from the tree)

Fixed on trunk.

Do we want this patch on the 1.8/1.8.0 branches? The code it's patching is the same regardless of whether this particular testcase crashes or not.

I'm actually not sure. A lot of the frame construction code is pretty different on the branches in subtle ways. :(

moving blocking1.8.1 back to nominated status, we're not sure we want this on the branch, or if we want it fixed but need a different patch.

I'm actually going to push this back to plus -- this patch doesn't look like it would be too hard to adapt to the branch, and I think there's another bug that may well be a duplicate of this one.

...I was thinking of bug 344340.

I think this is safe enough. Can't test it, though, since I can't reproduce the crash like I said above.

Comment on attachment 234843 [details] [diff] [review] Branch version of the patch approved for 1.8.0 branch, a=dveditz for drivers

Comment on attachment 234843 [details] [diff] [review] Branch version of the patch a=schrep for drivers - approving all [181approval pending] bugs now that tree is open.

Fixed on both branches.

with 20060823 builds unreduced testcase https://bugzilla.mozilla.org/attachment.cgi?id=194750 1.8.0.7 linux nightly crash tb22442419 debug crash ditto stack winxp nightly crash, no tb debug crash like bug 311457 1.8 linux nightly crash tb22430886, tb22440331 debug crash ditto stack 1.8 winxp nightly crash, no tb debug crash like bug 311457 1.9 linux nightly no crash debug no crash 1.9 winxp nightly no crash debug crash @ gkwidget.dll!nsCOMPtr<nsIWidget>::assign_assuming_AddRef() Line 568 with oldPtr 0xfdfdfdfd => heap overrun somewhere. ###!!! ASSERTION: Bogus state: '!mLastChild->GetNextSibling()', file f:/work/mozilla/builds/ff/trunk/mozilla/widget/src/xpwidgets/nsBaseWidget.cpp, line 291 repeated with oldPtr 0xdddddddd reduced testcase https://bugzilla.mozilla.org/attachment.cgi?id=198670 1.8.0.7 linux nightly no crash debug no crash winxp nightly no crash debug no crash 1.8 linux nightly no crash debug no crash 1.8 winxp nightly no crash debug no crash 1.9 linux nightly no crash debug no crash 1.9 winxp nightly no crash debug no crash so, the reduced testcase is fixed, but the unreduced one isn't. Not going to verify this.

Hmm... That's a different stack from the one initially in this bug; we should probably file a separate bug on it... The 1.8.0.7 and 1.8.1 stacks look about the same to me, so it's likely to be the same issue. That said, my debug 1.8.1 branch Linux build is up to 120000 on the counter in the status bar right now and running fine. Bob, how long did it take you to crash?

I do crash on quit in the build from comment 35 with a stack sorta like: #13 0xb72634ff in nsWidget::GetParent (this=0xb0eddc38) at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:429 #14 0xb7278a97 in nsBaseWidget::Destroy (this=0xb0eddc38) at ../../../../mozilla/widget/src/xpwidgets/nsBaseWidget.cpp:244 #15 0xb72632af in nsWidget::Destroy (this=0xb0eddc38) at ../../../../mozilla/widget/src/gtk/nsWidget.cpp:355 #16 0xb726a69b in nsWindow::Destroy (this=0xb0eddc38) at ../../../../mozilla/widget/src/gtk/nsWindow.cpp:425 #17 0xb7269fe7 in ~nsWindow (this=0xb0eddc38) at ../../../../mozilla/widget/src/gtk/nsWindow.cpp:372 Not sure what the deal is there. I'll try a GTK2 build.

OK, a GTK2 build crashes, looks like. :(

(gdb) frame #6 0xb6c9c17e in HandleEvent (aEvent=0xbfffe330) at ../../../mozilla/view/src/nsView.cpp:171 171 view->GetViewManager()->DispatchEvent(aEvent, &result); (gdb) p view $7 = (nsView *) 0x9314be8 (gdb) p *view $8 = {<nsIView> = {_vptr.nsIView = 0x740068, mViewManager = 0x700074, mParent = 0x2f003a, mWindow = 0x77002f, mNextSibling = 0x770077, (gdb) whats view 0x740068: Cannot access memory at address 0x740068 So this view is dead, with bogus vtable pointers and such... That's about all I can tell offhand; a smaller testcase would be lovely. :(

(In reply to comment #35) > > That said, my debug 1.8.1 branch Linux build is up to 120000 on the counter in > the status bar right now and running fine. Bob, how long did it take you to > crash? for the unreduced testcase running in a vm with fedora core5 counter reads ~2000-2100 before 1.8 crashes. On the widget trunk crash I filed bug 349974. Note the comments about allowing the script to update the status bar hiding the bug. Boris, turn off status bar updating via script and see what happens.

Verified fixed by testing with "simpler testcase, involves "display: -moz-popup"". That testcase doesn't crash anymore, using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b2) Gecko/20060830 BonEcho/2.0b2 and: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060829 Firefox/1.5.0.7 Firefox1.5.0.6 crashes on the simpler testcase. I believe bug 349974 is filed on the issue that the not reduced testcase is still crashing. Please correct me, if I'm wrong.

linux crash on unreduced testcase filed in Bug 353008

Crashtest is in. I modified it to use document.documentElement.offsetHeight instead of setTimeout, and verified that it still crashed a 2005-10-05 nightly.