The default bug view has changed. See this FAQ.

crash involving -moz-popup [@ IncrementalReflow::AddCommand]

VERIFIED FIXED in mozilla1.9alpha1

Status

()

Core
Layout
P1
critical
VERIFIED FIXED
12 years ago
6 years ago

People

(Reporter: Jesse Ruderman, Assigned: bz)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla1.9alpha1
crash, testcase, verified1.8.0.7, verified1.8.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 +
blocking1.8.0.7 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical], crash signature)

Attachments

(5 attachments, 2 obsolete attachments)

(Reporter)

Description

12 years ago
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.
(Reporter)

Comment 1

12 years ago
Created attachment 194749 [details]
apple crash report with stack trace
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.
(Reporter)

Comment 5

12 years ago
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
(Reporter)

Comment 6

12 years ago
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
(Reporter)

Comment 7

12 years ago
Doesn't crash for me in a debug build on Mac.  I see and hear hundreds of
assertion failures, though.
(Reporter)

Comment 8

12 years ago
Created attachment 195358 [details]
15 assertion failure messages, sorted by frequency
(Reporter)

Comment 9

12 years ago
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].
(Reporter)

Comment 10

12 years ago
On Windows XP: WFM with today's trunk, still crashes with today's Gecko1.8 branch.
(Reporter)

Comment 11

12 years ago
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.
Depends on: 307809
(Reporter)

Comment 12

12 years ago
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.
No longer depends on: 307809
(Reporter)

Comment 13

12 years ago
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.
(Reporter)

Updated

12 years ago
Keywords: 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...
(Reporter)

Comment 15

12 years ago
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.
Created attachment 198717 [details] [diff] [review]
Something to try

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

Comment 17

12 years ago
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.
(Reporter)

Comment 18

12 years ago
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.
(Reporter)

Comment 20

12 years ago
Filed bug 311457 for the crash mentioned in comment 18.
(Reporter)

Updated

12 years ago
Summary: Trunk RandomStyles crash [@ IncrementalReflow::AddCommand] → Trunk RandomStyles crash involving -moz-popup [@ IncrementalReflow::AddCommand]
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)
Attachment #198717 - Flags: superreview?(roc)
Attachment #198717 - Flags: review?(roc)
Blocks: 317724
Blocks: 311457
Attachment #198717 - Flags: superreview?(roc)
Attachment #198717 - Flags: superreview+
Attachment #198717 - Flags: review?(roc)
Attachment #198717 - Flags: review+
Created attachment 205334 [details] [diff] [review]
Updated to tip
Assignee: nobody → bzbarsky
Attachment #198717 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Fixed on trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
OS: MacOS X → All
Priority: -- → P1
Hardware: Macintosh → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha

Updated

11 years ago
Flags: testcase+
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.
Flags: blocking1.8.1?
Flags: blocking1.8.0.6?

Updated

11 years ago
Flags: blocking1.8.1? → blocking1.8.1+
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.
Flags: blocking1.8.1+ → blocking1.8.1?
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.
Flags: blocking1.8.1? → blocking1.8.1+
...I was thinking of bug 344340.
Flags: blocking1.8.0.7? → blocking1.8.0.7+

Updated

11 years ago
Target Milestone: mozilla1.9alpha → mozilla1.8.1
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.
Attachment #234843 - Flags: approval1.8.1?
Attachment #234843 - Flags: approval1.8.0.7?

Updated

11 years ago
Whiteboard: [181approval pending]
Comment on attachment 234843 [details] [diff] [review]
Branch version of the patch

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #234843 - Flags: approval1.8.0.7? → approval1.8.0.7+

Comment 31

11 years ago
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.
Attachment #234843 - Flags: approval1.8.1? → approval1.8.1+
Created attachment 235040 [details] [diff] [review]
Branch version for real (without admixed cruft from other bugs)
Attachment #234843 - Attachment is obsolete: true
Fixed on both branches.
Keywords: fixed1.8.0.7, fixed1.8.1
Whiteboard: [181approval pending]
Target Milestone: mozilla1.8.1 → mozilla1.9alpha

Comment 34

11 years ago
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.  :(

Comment 39

11 years ago
(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.
Whiteboard: [sg:critical]
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.
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.0.7, fixed1.8.1 → verified1.8.0.7, verified1.8.1

Comment 41

11 years ago
linux crash on unreduced testcase filed in Bug 353008

Updated

10 years ago
Flags: in-testsuite+ → in-testsuite?
Summary: Trunk RandomStyles crash involving -moz-popup [@ IncrementalReflow::AddCommand] → crash involving -moz-popup [@ IncrementalReflow::AddCommand]
Group: security
(Reporter)

Comment 42

9 years ago
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.
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ IncrementalReflow::AddCommand]
You need to log in before you can comment on or make changes to this bug.