46556 - Crash after change theme [@ DocumentViewerImpl::MakeWindow]

Status: VERIFIED FIXED

(Core Graveyard :: Skinability, defect, P3)

Description

[Teruko Kobayashi]

Netscape will crash when you type URL after you change themes.

Steps of reproduce
1. Open Preferences dialog to change theme to classic
2. Try to change the URL in the Classic theme
Netscape will crash.  

Tested 2000-07-26-08 Win32, MAC and Linux build.  I could reproduce this in Win
and Mac build.  I could not reproduce this in Linux build.

Talkback incident #14845522
 Trigger Type:  Program Crash 
 Call Stack:    (Signature = DocumentViewerImpl::MakeWindow 8c07b6ea) 
   DocumentViewerImpl::MakeWindow 
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 1054]
   DocumentViewerImpl::Init 
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 535]
   nsDocShell::SetupNewViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2591]
   nsWebShell::SetupNewViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 389]
   nsDocShell::Embed 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2249]
   nsWebShell::Embed 
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 413]
   nsDocShell::CreateContentViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2418]
   nsDSURIContentListener::DoContent 
[d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 101]
   nsDocumentOpenInfo::DispatchContent 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 362]
   nsDocumentOpenInfo::OnStartRequest 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 234]
   nsHTTPFinalListener::OnStartRequest 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 1151]
   InterceptStreamListener::OnStartRequest 
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1151]
   nsHTTPServerListener::FinishedResponseHeaders
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 1089]
   nsHTTPServerListener::OnDataAvailable 
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 425]
   nsOnDataAvailableEvent::HandleEvent 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
406]
   nsStreamListenerEvent::HandlePLEvent 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 
106]
   PL_HandleEvent 
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 588]
   PL_ProcessPendingEvents 
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 547]
   _md_EventReceiverProc 
[d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1045]
     
   USER32.dll + 0x1186 (0x77e41186)

Comment 1

[hangas]

Sending to Skinability...

Comment 2

[Blake Ross]

bleh.  Yes, I see this too. nsbeta2.  cc'ing people

Comment 3

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 4

[Chris McAfee]

I suggest release-noting this in lieu of update from ben.

Comment 5

[leger]

shrir just reproduce this with Win NT on 2000-07-28-12-M17 commercial PR2 branch 
build.

Comment 6

[leger]

Adding shrir to cc.  Investigating what other platforms/OSs this is on.  Marking 
ETA ??? til we get fix info.

Comment 7

[Dan M]

  (Speaking as temporary steward of this bug) I can't reproduce the problem. I'm 
a little unclear on the exact steps. Launch the browser in the Modern theme, 
switch to Classic, and type a few characters into the URL bar of the browser, 
right? I've done that and gone so far as to type an entire URL in and load it. No 
problems. On three Windows 2000 boxes, one Windows 98 box, a linux box and two 
Macs.
  On one of the Win2K boxes, I tried a homespun build from this morning's source, 
as well as the 2000-07-26-09-M17 and 2000-07-28-09-M18 prefabs. No problems. 
Still trying. Left a message for shrir.

Comment 8

[chris hofmann]

I couldn't reproduce on the NT pitcam machine but
edit | prefs | themes 
select classic - change theme
then hit reload crashed my win95 laptop...
-stacktrace comming

Comment 9

[Dan M]

  Alright. I've seen it happen twice now, not when typing in the 
URL bar, but after hitting "return" to load a page, when the page is http://
home.netscape.com/index.html. I'm looking. More later.

Comment 10

[chris hofmann]

Attachment: skin switch crash/Call Stack Signature contains DocumentViewerImpl::MakeWindow

Comment 11

[chris hofmann]

interesting that one of the comments with this stack trace is
clicking around netscape.com site; several redirect pages were not
added to SH; did Go->Home; urlbar not updated; type in urlbar hit return 
crash.  

maybe this is more of a session history bug of the ilk that 
radha and nisheeth are looking at... 

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

Neither Dan nor I are appropriate owners for this bug. I want to thank Dan for 
taking as much time as he has to look at it. If he decides he can't figure it 
out or doesn't want to spend any more time on it, a more appropriate owner might 
be rpotts..?

Comment 13

[Stephen P. Morse]

I don't know if this is related or not, but there's a whole section of the 
theme's pref panel that's missing.  That's because the xul for <tabcontrol> is 
broken as of today's build.  See bug 46817.

Comment 14

[Jan Carpenter]

I was able to get this crash one time on Win98 using build: 
2000-07-28-12-M17

Here is the Talkback report:

Incident ID 14953212 
 Trigger Time 
            2000-07-28 18:24:16 
 Email Address 
            [e-mail] 
 User Comments 
            Crash after changing Theme and entering new URL 
 Build ID
            2000072812 
 Product ID
            Netscape6 
 Platform ID
            Win32 
 Stack Trace

DocumentViewerImpl::MakeWindow 
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 1054] 
DocumentViewerImpl::Init 
[d:\builds\seamonkey\mozilla\layout\base\src\nsDocumentViewer.cpp, line 535] 
nsDocShell::SetupNewViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2591] 
nsWebShell::SetupNewViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, line 395] 
nsDocShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, 
line 2249] 
nsWebShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsWebShell.cpp, 
line 419] 
nsDocShell::CreateContentViewer 
[d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2418] 
nsDSURIContentListener::DoContent 
[d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 101] 
nsDocumentOpenInfo::DispatchContent 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 362] 
nsDocumentOpenInfo::OnStartRequest 
[d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 234] 
nsHTTPFinalListener::OnStartRequest
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 1151] 
InterceptStreamListener::OnStartRequest 
[d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line
1151] 
nsHTTPServerListener::FinishedResponseHeaders
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 1089] 
nsHTTPServerListener::OnDataAvailable
[d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp
p, line 425] 
nsOnDataAvailableEvent::HandleEvent 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
406] 
nsStreamListenerEvent::HandlePLEvent 
[d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line
106] 
PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 588] 
PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, 
line 547] 
_md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 
1045] 
KERNEL32.DLL + 0x363b (0xbff7363b) 
KERNEL32.DLL + 0x24407 (0xbff94407) 
0x00688b42 

Comment 15

[Dan M]

  Happy New Bug, David -- nsBrowserInstance, the bane of your existence, is back. 
Assigning to Mr Skin, an apt name if you've ever seen him. Here's how to 
reproduce the bug:

  Launch Mozilla browser window with the Modern Theme active (I'm not sure if 
it's important which theme, but this is all I've ever tried)
  Load http://home.netscape.com/index.html (I did it by typing in the URL bar; 
that's no doubt unimportant)
  Open Preferences, switch to the Classic Theme. Close Preferences.
  Click in the URL bar, hit "return" to reload the page.

  That's it. The problem is the browser window's content area docshell. This is 
theoretically torn down and replaced along with the whole frame hierarchy when 
the skin is switched. However, in this case, it leaks. There are still three 
references holding it alive, even though it has been destroyed (that is, had its 
Destroy method called.) I haven't managed to figure out who those three objects 
are. Probably something to do with the netscape page load. Not to cast 
aspersions, but maybe an nsHTTPChannel, or something. I don't know.
  Fast forward to the crash. Comes a time, eventually, when nsBrowserInstance 
wants to fetch its content area docshell. It's clever enough to hold a weak 
reference which it can regenerate when needed. But the weak reference hasn't been 
cut because the docshell still exists, if only a zombie.
  This very bad patch, which I include for illustrative purposes only, stops the 
crash:

--- ./xpfe/browser/src/nsBrowserInstance.cpp.1.142
 
+#include "nsIBaseWindow.h"
 nsIDocShell* 
 nsBrowserInstance::GetContentAreaDocShell()
 {
   nsCOMPtr<nsIDocShell> docShell(do_QueryReferent(mContentAreaDocShellWeak));
+  if (docShell) {
+    // the docshell still exists, but has it been destroyed?
+    nsCOMPtr<nsIBaseWindow> hack = do_QueryInterface(docShell);
+    if (hack) {
+      nsIWidget *parent;
+      hack->GetParentWidget(&parent);
+      if (!parent)
+        // it's a zombie. let it leak, and set up to reinitialize with the new 
one
+        docShell = 0;
+    }
+  }
   if (!docShell)
     ReinitializeContentVariables();
   docShell = do_QueryReferent(mContentAreaDocShellWeak);

  That said, I should point out that Waterson and I have occasionally seen a 
crash under these circumstances with another stack trace that looks nothing like 
any of this.
  So the problem is a leaking nsDocShell which tricks the nsBrowserInstance into 
using it after it's been zombified, and that quickly leads to a null dereference. 
Now what?

Comment 16

[David Hyatt]

Since we're going to kill nsBrowserInstance, I'd be inclined to take this patch 
for nsbeta2+.  It looks good to me.

r=hyatt

Comment 17

[Peter "jag" Annema]

This crashes for me on Windows 95 2000072808 M18 and Linux 2000072908 M18, non 
talkback.

And just got a talkback version to crash. Win 95, 2000072908 M18.
See TB14992610X, TB14992616M, TB14992728X and TB14993232Z. I claim my donut(s) 
;-)

Comment 18

[leger]

Per shrir via mail;
"I could repro this on today's m17 linux (2000073104m17). Mac m17 looks 
fine(2000073104m17) (I could not crash). Crashes on all windows flavours (also 
mentioned in the bug"

Comment 19

[shrirang khanzode]

with a little persistence..mac m17(2000073108)crashes too .Changing OS: ALL.

Comment 20

[leger]

Updating ETA to 7/31

Comment 21

[Dan M]

  There were two crashes here, the one described, in 
DocumentViewImpl::MakeWindow, and another less common one in 
nsMenuListener::KeyPress. I believe I've got 'em both. Trunk and M17 branch.

Comment 22

[Paul Wyskoczka]

Verified in build 2000080104 on WinNT, Mac, and Linux