Last Comment Bug 306940 - crash involving -moz-popup [@ IncrementalReflow::AddCommand]
: crash involving -moz-popup [@ IncrementalReflow::AddCommand]
Status: VERIFIED FIXED
[sg:critical]
: crash, testcase, verified1.8.0.7, verified1.8.1
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
: P1 critical (vote)
: mozilla1.9alpha1
Assigned To: Boris Zbarsky [:bz] (still a bit busy)
:
:
Mentors:
Depends on:
Blocks: randomstyles 311457 317724
  Show dependency treegraph
 
Reported: 2005-09-03 01:48 PDT by Jesse Ruderman
Modified: 2011-06-13 10:01 PDT (History)
9 users (show)
dbaron: blocking1.8.1+
dveditz: blocking1.8.0.7+
jruderman: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
apple crash report with stack trace (19.04 KB, text/plain)
2005-09-03 01:49 PDT, Jesse Ruderman
no flags Details
15 assertion failure messages, sorted by frequency (2.18 KB, text/plain)
2005-09-08 20:49 PDT, Jesse Ruderman
no flags Details
simpler testcase, involves "display: -moz-popup" (748 bytes, text/html)
2005-10-05 22:36 PDT, Jesse Ruderman
no flags Details
Something to try (2.40 KB, patch)
2005-10-06 12:32 PDT, Boris Zbarsky [:bz] (still a bit busy)
roc: review+
roc: superreview+
Details | Diff | Splinter Review
Updated to tip (2.38 KB, patch)
2005-12-08 13:59 PST, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review
Branch version of the patch (6.71 KB, patch)
2006-08-21 14:31 PDT, Boris Zbarsky [:bz] (still a bit busy)
dveditz: approval1.8.0.7+
mtschrep: approval1.8.1+
Details | Diff | Splinter Review
Branch version for real (without admixed cruft from other bugs) (2.41 KB, patch)
2006-08-22 20:59 PDT, Boris Zbarsky [:bz] (still a bit busy)
no flags Details | Diff | Splinter Review

Description Jesse Ruderman 2005-09-03 01:48:24 PDT
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.
Comment 1 Jesse Ruderman 2005-09-03 01:49:01 PDT
Created attachment 194749 [details]
apple crash report with stack trace
Comment 3 Boris Zbarsky [:bz] (still a bit busy) 2005-09-05 21:22:16 PDT
Hmm... I can't seem to reproduce a crash here (been running that testcase for
about 10 mins now).
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2005-09-05 21:23:09 PDT
That's with a Linux trunk MOZ_CO_DATE="Fri Sep 2 22:10:00 CDT 2005" build.
Comment 5 Jesse Ruderman 2005-09-06 01:48:37 PDT
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
Comment 6 Jesse Ruderman 2005-09-08 18:19:19 PDT
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
Comment 7 Jesse Ruderman 2005-09-08 20:47:04 PDT
Doesn't crash for me in a debug build on Mac.  I see and hear hundreds of
assertion failures, though.
Comment 8 Jesse Ruderman 2005-09-08 20:49:29 PDT
Created attachment 195358 [details]
15 assertion failure messages, sorted by frequency
Comment 9 Jesse Ruderman 2005-09-23 21:26:45 PDT
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].
Comment 10 Jesse Ruderman 2005-10-04 17:40:44 PDT
On Windows XP: WFM with today's trunk, still crashes with today's Gecko1.8 branch.
Comment 11 Jesse Ruderman 2005-10-05 01:00:23 PDT
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.
Comment 12 Jesse Ruderman 2005-10-05 18:05:29 PDT
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.
Comment 13 Jesse Ruderman 2005-10-05 22:36:51 PDT
Created attachment 198670 [details]
simpler testcase, involves "display: -moz-popup"

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.
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2005-10-06 11:26:27 PDT
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...
Comment 15 Jesse Ruderman 2005-10-06 11:51:49 PDT
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.
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2005-10-06 12:32:33 PDT
Created attachment 198717 [details] [diff] [review]
Something to try

Yeah, I'm on Linux.  Try this, see what happens?
Comment 17 Jesse Ruderman 2005-10-06 18:46:06 PDT
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.
Comment 18 Jesse Ruderman 2005-10-06 18:51:53 PDT
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.
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2005-10-06 19:58:31 PDT
Might not be a bad idea (with a separate bug) -- I can't reproduce that crash on
the "testcase (not reduced)" testcase.
Comment 20 Jesse Ruderman 2005-10-06 22:33:14 PDT
Filed bug 311457 for the crash mentioned in comment 18.
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2005-11-26 09:57:44 PST
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)
Comment 22 Boris Zbarsky [:bz] (still a bit busy) 2005-12-08 13:59:56 PST
Created attachment 205334 [details] [diff] [review]
Updated to tip
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2005-12-08 15:09:50 PST
Fixed on trunk.
Comment 24 Daniel Veditz [:dveditz] 2006-07-06 19:24:27 PDT
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.
Comment 25 Boris Zbarsky [:bz] (still a bit busy) 2006-07-14 13:53:19 PDT
I'm actually not sure.  A lot of the frame construction code is pretty different on the branches in subtle ways.  :(
Comment 26 Daniel Veditz [:dveditz] 2006-07-27 17:12:08 PDT
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.
Comment 27 David Baron :dbaron: ⌚️UTC-7 2006-07-28 10:22:15 PDT
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.
Comment 28 David Baron :dbaron: ⌚️UTC-7 2006-07-28 10:25:50 PDT
...I was thinking of bug 344340.
Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2006-08-21 14:31:05 PDT
Created attachment 234843 [details] [diff] [review]
Branch version of the patch

I think this is safe enough.  Can't test it, though, since I can't reproduce the crash like I said above.
Comment 30 Daniel Veditz [:dveditz] 2006-08-22 14:40:33 PDT
Comment on attachment 234843 [details] [diff] [review]
Branch version of the patch

approved for 1.8.0 branch, a=dveditz for drivers
Comment 31 Mike Schroepfer 2006-08-22 18:40:53 PDT
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.
Comment 32 Boris Zbarsky [:bz] (still a bit busy) 2006-08-22 20:59:47 PDT
Created attachment 235040 [details] [diff] [review]
Branch version for real (without admixed cruft from other bugs)
Comment 33 Boris Zbarsky [:bz] (still a bit busy) 2006-08-22 21:02:15 PDT
Fixed on both branches.
Comment 34 Bob Clary [:bc:] 2006-08-23 21:44:11 PDT
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.
Comment 35 Boris Zbarsky [:bz] (still a bit busy) 2006-08-23 21:58:26 PDT
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?
Comment 36 Boris Zbarsky [:bz] (still a bit busy) 2006-08-23 22:02:43 PDT
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.
Comment 37 Boris Zbarsky [:bz] (still a bit busy) 2006-08-23 22:04:43 PDT
OK, a GTK2 build crashes, looks like.  :(
Comment 38 Boris Zbarsky [:bz] (still a bit busy) 2006-08-23 22:09:49 PDT
(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.  :(
Comment 39 Bob Clary [:bc:] 2006-08-23 22:25:22 PDT
(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.
Comment 40 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-08-30 14:39:47 PDT
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.
Comment 41 Bob Clary [:bc:] 2006-09-16 15:26:40 PDT
linux crash on unreduced testcase filed in Bug 353008
Comment 42 Jesse Ruderman 2007-12-11 20:50:43 PST
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.

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