Crash [@ HandleEvent] on reload with treechildren with display: -moz-deck inside tabpanels

VERIFIED FIXED

Status

()

Core
XUL
--
critical
VERIFIED FIXED
11 years ago
6 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: Mats Palmgren (vacation - back in August))

Tracking

(4 keywords)

Trunk
x86
All
crash, testcase, verified1.8.0.13, verified1.8.1.5
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1.5 +
wanted1.8.1.x +
blocking1.8.0.13 +
wanted1.8.0.x +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:critical] using freed view [must go before 140218 on branches], crash signature)

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
Created attachment 258693 [details]
testcase

See testcase, which crashes current trunk builds on reload.

Talkback ID: TB30268064E
HandleEvent  [mozilla/view/src/nsview.cpp, line 171]
nsWindow::DispatchEvent  [mozilla/widget/src/windows/nswindow.cpp, line 1103]
nsWindow::DispatchStandardEvent  [mozilla/widget/src/windows/nswindow.cpp, line 1143]
nsWindow::OnDestroy  [mozilla/widget/src/windows/nswindow.cpp, line 5812]
kModuleInfo
nsWindow::StandardWindowCreate  [mozilla/widget/src/windows/nswindow.cpp, line 1359]
0x5604508b

It also crashes Firefox2.0.0.3pre and Mozilla1.7.13 directly, so it's not a regression. So I'm marking this security sensitive.
(Reporter)

Comment 1

11 years ago
I filed bug 374103 as the branch version of this bug.
I can reproduce this on a Windows debug and nightly build, but not on a Mac debug build.
Whiteboard: [sg:critical]

Comment 3

11 years ago
I see the following assertion just before the crash
###!!! ASSERTION: We already have a window for this view? BAD: '!mWindow', file /home/smaug/mozilla/mozilla_cvs/mozilla/view/src/nsView.cpp, line 612
WARNING: empty langgroup: file /home/smaug/mozilla/mozilla_cvs/mozilla/gfx/thebes/src/gfxFont.cpp, line 503
Flags: wanted1.8.1.x?
Flags: wanted1.8.0.x?
Whiteboard: [sg:critical] → [sg:critical] see bug 374103 for 1.8-branch version

Comment 4

10 years ago
I take this for now, will look at later this week.
Jan, if you were working on this, feel free to reassign.
Assignee: Jan.Varga → Olli.Pettay
The testcase results in this assertion a bit before the crash:
###!!! ASSERTION: We already have a window for this view? BAD: '!mWindow', file nsView.cpp, line 612

The widget was already created by nsLeafBoxFrame::Init()
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/xul/base/src/nsLeafBoxFrame.cpp&rev=1.60&root=/cvsroot&mark=107,108#94
but nsTreeBodyFrame::Init() does not check this
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/xul/base/src/tree/src/nsTreeBodyFrame.cpp&rev=1.313&root=/cvsroot&mark=211#205
Assignee: Olli.Pettay → mats.palmgren
OS: Windows XP → All
Created attachment 264162 [details] [diff] [review]
Patch rev. 1
Attachment #264162 - Flags: superreview?(roc)
Attachment #264162 - Flags: review?(roc)
The testcase crashes my branch debug builds (Linux debug), it's a null-deref
which is bug 140218.  Fixing bug 140218 however makes the crash the same as
on trunk, that is using a destroyed view on Reload...
Whiteboard: [sg:critical] see bug 374103 for 1.8-branch version → [sg:critical] using freed view, see bug 374103 for 1.8-branch version
Created attachment 264183 [details]
stack

Analyzing the crash a little deeper - when the assert occurs we
just release the ref to the old mWindow and set up the new
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/view/src/nsView.cpp&rev=3.236&root=/cvsroot&mark=612-613#602

This is no good since the old window still references the view
we now have two windows pointing to this view.  When the view
is destroyed it only tears down the "client data" for the
latest window so the first one has a dangling pointer so 
when it is destroyed it will fire an OnDestroy event
on a deleted view.
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/view/src/nsView.cpp&rev=3.236&root=/cvsroot&mark=167,171#162

This is the stack and trace of calls leading up to the crash.
Created attachment 264186 [details] [diff] [review]
Additional patch

Here's a patch that make the code more robust against this kind
of error in the future.  In fact, this patch fixes the crash alone
(at least in my debug trunk build on Linux).
The layout/xul changes in the first patch avoids causing the error
with two widgets for the same view in the first place.
We should probably take both patches.
Blocks: 321224
Blocks: 330480
Blocks: 283154
Attachment #264162 - Flags: superreview?(roc)
Attachment #264162 - Flags: superreview+
Attachment #264162 - Flags: review?(roc)
Attachment #264162 - Flags: review+
Attachment #264186 - Flags: superreview+
Attachment #264186 - Flags: review+
Both patches checked in to trunk at 2007-05-13 17:42 PDT.

-> FIXED
Blocks: 140218
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Whiteboard: [sg:critical] using freed view, see bug 374103 for 1.8-branch version → [sg:critical] using freed view [must go before 140218 on branches]
Created attachment 264700 [details] [diff] [review]
One more addition, for branches only

Fix same problem in nsNativeScrollbarFrame.cpp, this is only needed
on branches since this file has been removed on trunk.
This patch alone fixes bug 321224, but I prefer to handle all the patches
on this bug.
Attachment #264700 - Flags: superreview?(roc)
Attachment #264700 - Flags: review?(roc)
(Reporter)

Comment 12

10 years ago
Thanks, verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070514 Minefield/3.0a5pre
(Reporter)

Updated

10 years ago
Status: RESOLVED → VERIFIED
Flags: wanted1.8.1.x?
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x?
Flags: wanted1.8.0.x+
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Attachment #264700 - Flags: superreview?(roc)
Attachment #264700 - Flags: superreview+
Attachment #264700 - Flags: review?(roc)
Attachment #264700 - Flags: review+
Attachment #264700 - Flags: approval1.8.1.5?
Attachment #264700 - Flags: approval1.8.0.13?
Attachment #264186 - Flags: approval1.8.1.5?
Attachment #264186 - Flags: approval1.8.0.13?
Attachment #264162 - Flags: approval1.8.1.5?
Attachment #264162 - Flags: approval1.8.0.13?
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Comment on attachment 264162 [details] [diff] [review]
Patch rev. 1

approved for 1.8.1.5 and 1.8.0.13, a=dveditz for release-drivers
Attachment #264162 - Flags: approval1.8.1.5?
Attachment #264162 - Flags: approval1.8.1.5+
Attachment #264162 - Flags: approval1.8.0.13?
Attachment #264162 - Flags: approval1.8.0.13+
Attachment #264186 - Flags: approval1.8.1.5?
Attachment #264186 - Flags: approval1.8.1.5+
Attachment #264186 - Flags: approval1.8.0.13?
Attachment #264186 - Flags: approval1.8.0.13+
Attachment #264700 - Flags: approval1.8.1.5?
Attachment #264700 - Flags: approval1.8.1.5+
Attachment #264700 - Flags: approval1.8.0.13?
Attachment #264700 - Flags: approval1.8.0.13+
All three patches landed on MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH
at 2007-07-01 14:30 PDT.
Keywords: fixed1.8.0.13, fixed1.8.1.5
verified fixed 1.8.1.5. using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.1.5pre) Gecko/20070704 BonEcho/2.0.0.5pre ID:2007070403 and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5pre) Gecko/2007070403 BonEcho/2.0.0.5pre on Linux Fedora F7- no crash on Testcase - adding verified keyword
Keywords: fixed1.8.1.5 → verified1.8.1.5
Verified on MacIntel using version 1.5.0.13 (20070809) and testcase in comment #0. No longer crashes.
Keywords: fixed1.8.0.13 → verified1.8.0.13
Group: security

Updated

9 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: xptoolkit.trees → xptoolkit.widgets

Comment 17

8 years ago
crash test landed
http://hg.mozilla.org/mozilla-central/rev/27013d682d9f
Flags: in-testsuite? → in-testsuite+
Crash Signature: [@ HandleEvent]
You need to log in before you can comment on or make changes to this bug.