Created attachment 258693 [details]
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]
nsWindow::StandardWindowCreate [mozilla/widget/src/windows/nswindow.cpp, line 1359]
It also crashes Firefox126.96.36.199pre and Mozilla1.7.13 directly, so it's not a regression. So I'm marking this security sensitive.
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.
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
I take this for now, will look at later this week.
Jan, if you were working on this, feel free to reassign.
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()
but nsTreeBodyFrame::Init() does not check this
Created attachment 264162 [details] [diff] [review]
Patch rev. 1
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...
Created attachment 264183 [details]
Analyzing the crash a little deeper - when the assert occurs we
just release the ref to the old mWindow and set up the new
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.
This is the stack and trace of calls leading up to the crash.
Created attachment 264186 [details] [diff] [review]
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.
Both patches checked in to trunk at 2007-05-13 17:42 PDT.
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.
Thanks, verified fixed, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070514 Minefield/3.0a5pre
Comment on attachment 264162 [details] [diff] [review]
Patch rev. 1
approved for 188.8.131.52 and 184.108.40.206, a=dveditz for release-drivers
All three patches landed on MOZILLA_1_8_BRANCH and MOZILLA_1_8_0_BRANCH
at 2007-07-01 14:30 PDT.
verified fixed 220.127.116.11. using Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:18.104.22.168pre) Gecko/20070704 BonEcho/22.214.171.124pre ID:2007070403 and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199pre) Gecko/2007070403 BonEcho/188.8.131.52pre on Linux Fedora F7- no crash on Testcase - adding verified keyword
Verified on MacIntel using version 184.108.40.206 (20070809) and testcase in comment #0. No longer crashes.
crash test landed