92291 - Crash logging into waterhouse.

Status: RESOLVED FIXED

(SeaMonkey :: General, defect, P2)

Description

[John Unruh]

7/25 Branch WinNT build.
1.) With a new profile, or all ssl warnings turned on, visit the above URL.
2.) Enter bogus info into Name and Password, and login.
3.) Click OK on two security warnings.
What happens: Clicking OK on the final warning "You have requested a secure 
document. The document and any information you send back are encrypted for 
privacy while in transit." causes the crash.
Talkback - http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=33329840
The talkback appears to be the same as bug 88120.
Also fails on Win98 in netscp6. Crashes on Mac and Linux. Works on Win2000.

Comment 1

[John Unruh]

Actually it fails on Win2000 also when a bogus password is used. The workaround 
seems to be to put in a real account name and password.

Comment 2

[chris hofmann]

posting the stack trace

Incident ID 33329840
Stack Signature 0x02d92f14 2fa73740
Bug ID
Trigger Time 2001-07-25 11:24:43
User Comments logged onto waterhouse acct. enter acct info, then get "Do you
want Psswd Mgr to remember your login?" Press No. Then get "You have requested a
secure doc". Press OK. Then we get the crash.
Build ID 2001072506
Product ID Netscape6.10
Platform ID Win32
Stack Trace
0x02d92f14
ViewportFrame::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 142]
FrameManager::Destroy
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 457]
PresShell::~PresShell
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 1494]
PresShell::`scalar deleting destructor'
nsTextInputListener::Release
[d:\builds\seamonkey\mozilla\layout\html\forms\src\nsGfxTextControlFrame2.cpp,
line 235]
nsCOMPtr_base::~nsCOMPtr_base
[d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 50]
GlobalWindowImpl::Focus
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1783]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 594]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5564]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5496]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2056]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 724]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4429]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3345]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 989]
USER32.dll + 0x1303 (0x77e71303)
USER32.dll + 0x1962 (0x77e71962)
ntdll.dll + 0x163ef (0x77f763ef)
GlobalWindowImpl::Focus
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1773]
nsWebShellWindow::HandleEvent
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 530]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 724]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4429]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3341]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 989]
USER32.dll + 0x1303 (0x77e71303)
USER32.dll + 0x1962 (0x77e71962)
ntdll.dll + 0x163ef (0x77f763ef)
USER32.dll + 0x1350 (0x77e71350)
nsWindow::DefaultWindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1015]
USER32.dll + 0x2c6a (0x77e72c6a)
USER32.dll + 0x2cf5 (0x77e72cf5)
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1000]
USER32.dll + 0x1303 (0x77e71303)
USER32.dll + 0x1962 (0x77e71962)
ntdll.dll + 0x163ef (0x77f763ef)
nsWebShellWindow::Destroy
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1744]
nsChromeTreeOwner::Destroy
[d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsChromeTreeOwner.cpp, line 228]
GlobalWindowImpl::ReallyCloseWindow
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 2395]
GlobalWindowImpl::CloseWindow
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 3163]
nsJSContext::ScriptEvaluated
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 1367]
nsJSContext::CallEventHandler
[d:\builds\seamonkey\mozilla\dom\src\base\nsJSEnvironment.cpp, line 949]
nsJSEventListener::HandleEvent
[d:\builds\seamonkey\mozilla\dom\src\events\nsJSEventListener.cpp, line 140]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1162]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
2134]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3635]
PresShell::HandleDOMEventWithTarget
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5617]
nsButtonBoxFrame::MouseClicked
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 181]
nsButtonBoxFrame::HandleEvent
[d:\builds\seamonkey\mozilla\layout\xul\base\src\nsButtonBoxFrame.cpp, line 128]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5586]
PresShell::HandleEventWithTarget
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5541]
nsEventStateManager::CheckForAndDispatchClick
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 2465]
nsEventStateManager::PostHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 1551]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5590]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5496]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 377]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2056]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 68]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 724]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 741] 

Comment 3

[saari (gone)]

I think this is a dup of 88120

Comment 4

[David P. Drinan]

The crash is being caused by the call to nsPromptService::DoDialog(). This 
method calls OpenWindow and the crash happens before that call returns. This 
smells like a window parenting problem. I need to track down someone in 
xptoolkit to figure this out.

Comment 5

[Dan M]

Paint suppression is focusing a Destroy()ed window. That's bad enough, but worse, 
the Destroy()ed window still carries a valid (non-null) pointer to its parent, 
which has also been Destroy()ed and destructed. The crash happens when an attempt 
is made to access this parent while focusing.

This patch fixes the crash:

Index: mozilla/widget/src/mac/nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/mac/nsWindow.cpp,v
retrieving revision 1.175
diff -u -2 -r1.175 nsWindow.cpp
--- nsWindow.cpp	2001/07/18 23:14:59	1.175
+++ nsWindow.cpp	2001/07/26 01:11:55
@@ -284,4 +284,5 @@
 	nsBaseWidget::OnDestroy();
 	nsBaseWidget::Destroy();
+	mParent = 0;
 	
   // just to be safe. If we're going away and for some reason we're still
@@ -2446,5 +2447,5 @@
 {
 	// currently, the nsMacEventHandler is owned by nsMacWindow, which is the 
top level window
-	// we deletgate this call to it's parent
+	// we delegate this call to its parent
   nsCOMPtr<nsIWidget> parent = getter_AddRefs(GetParent());
   NS_ASSERTION(parent, "cannot get parent");

nsBaseWidget::Destroy() removes the Destroy()ed window from its parent's child 
list. So it seems reasonable to clear the Destroy()ed window's parent reference 
at the same time. This patch causes an assertion: the focus code 
(ResetInputState, actually) is surprised when the window's parent is null. But it 
handles it, and there's no crash.

The underlying problem is of course, why the heck are we focusing a destroyed 
window? That I haven't looked into.

Comment 6

[lchiang]

danm - can we reassign this bug to you?

Comment 7

[John Unruh]

Adding relnote keyword. This release note wording (added to relnote bug 
90577) should cover bug 92291 and bug 88120.

Under rare circumstances, Netscape 6.1 may crash if certain security warnings 
are turned on.

These preferences are found under Edit, Preferences, Privacy and Security, SSL. 
Turning off the "Entering a site that supports encryption" and "Entering a site 
that uses low-grade encryption" warnings ahead of time is a workaround to 
preventing a crash.

Comment 8

[Dan M]

.

Comment 9

[David Epstein]

This also happens when logging into Schwab acct. Just make sure that "Enter a
site that supports encryption" is enabled in SSL prefs. Then go to
www.schwab.com, click on either login arrow, and OK "requesting secure doc" msg.

Comment 10

[Stephane Saux]

What build was it.
I just tried with trunk build linux 2001072606 and could not reproduce.

Comment 11

[David Epstein]

yesterday's 0.9.2 Win build.

Comment 12

[David P. Drinan]

On windows, the crash is happening in layout\html\base\src\nsPresShell.cpp:

  if (mViewManager) {
    // Disable paints during tear down of the frame tree
    mViewManager->DisableRefresh();                   <----- CRASHES HERE
    mViewManager = nsnull;
  }

From the debugger, the value of mViewManager is:
-	mViewManager	0x0598c0d0
-	nsISupports	{...}
+	__vfptr	0xdddddddd

The vtable pointer of mViewManagers nsISupports is messed up.

danm - who would be the right person in layout that could help us figure out why 
this is happening.

Comment 13

[David P. Drinan]

I should point out that the above comments refer to waterhouse.com and not to 
schwab.com. I do not crash at schwab.

Comment 14

[Dan M]

  David D: I'm don't see your crash on any platform. Your trace points to 
PresShell::EndObservingDocument which was I think the subject of a smoketest 
blocker fixed this morning. Might want to try again with a build, say, tomorrow.
  David E: www.schwab.com doesn't crash for me on Redhat, Win2k or Mac OS 9. 
(However I don't have a Schwab account, and it realizes this before I see any of 
the SSL warning dialogs.)
  So back to www.waterhouse.com. I'm crashing only on the Mac. My Win and Redhat 
builds have no problems. And my patch above affects only the Mac. However all 
platforms should probably be treated similarly in the interest of consistency. 
I'm attaching a patch that does up unix, mac and win and stops the crash on my 
builds, or those that had the crash in the first place.
  It seems reasonable, the patch: disconnect the parent from the child at the 
point where the child is disconnected from the parent. I've been running with it 
and had no problems. And the unix leak log claims no new leaks; a possibility. 
(Actually it claimed a couple fewer leaks, but that's probably a fluke.)

Comment 15

[Dan M]

Attachment: disconnect parent from child in Destroy (different on Windows)

Comment 16

[Stephane Saux]

There is some idea that a slow machine may increase the chance that the crash 
will happen. Using a Pentium 166 running windows95:
win 2001072506-0.9.2 build
www.schwab.com no crash
www.waterhouse.com crash
www.travel.com (from bug 88120) no crash.
For good measure I tried a few more sites like a credit union and etrade
and www.401k.com

Comment 17

[chris hofmann]

jay/tom,  lets search the talkback comments on trunk and 0.9.2 for instances
of comments or URLs with "waterhouse"
see if we can't turn up some common scenarios...

Comment 18

[greer]

Talkback data from the past ten days shows 8 crashes (other than the one 
above). None were from the Trunk and only three were from M092. (The others 
were 3 old, invalid crashes and two from Communicator 4.7x).

The three crashes in M092 were from two users:
33141214: 7/20/01 Down loading tdwaterhouse level II java applet

33254084, 33254037: 7/23/01 accessing bridge networks through tdwaterhouse.com

(The one Communicator4.77 with info was 33364982: Failed logging into 
www.tdwaterhouse.com)

I have emailed the users for further input.

Comment 19

[David Epstein]

The schwab.com crash was happening on WinNT 4.0, but it was with an existing
profile. I just tried it with a new profile I created and it didn't crash. Using
the old profile, the Schwab screen was different (i.e. it had an orange login
button while the new one had a Customer Login link). There are 2 talkback logs
on this under depstein: incidents 33417195 and 33380377. I didn't need to use
any Schwab acct info to reproduce because the crash occured before the login
screen appears. The waterhouse crash I found with my acct login. It was in an
unrecognized state because I needed to update some service agreement form. But
they only posted the form from a child login screen and not from the home page
login where I tried loggin in! Hence, it probably was treated as an unrecognized
acct.

Comment 20

[Dan M]

  Right, Stephane. This bug is an artifact of the paint suppression code, which 
makes it more likely to appear on slower machines. In my collection of machines, 
it looks like only my Mac is stepping in it.
  I've checked in the patch above that fixes the problem on my Mac, and then 
Linux and Windows equivalents. I'm having trouble locating machines to make sure 
those other two patches actually help, though I can say that they don't hurt. 
Fingers crossed, I'm calling it fixed. Ow. Hard to type that way. I'd appreciate 
anyone who has this problem on Linux or Windows giving the change a try.

Comment 21

[Stephane Saux]

When was this fixed. The comments lack the check in mention.

Comment 22

[Dan M]

2001-08-01 17:28