131841 - Crash on transition from secure to normal site - [@ nsCOMPtr_base::assign_with_AddRef] [@ nsDOMWindowList::GetLength]

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[bht237]

This is created as offspring from bug 102341. The crash occurrs at exactly the
same point, however the stack trace seems to indicate that it is a different
problem now.
A testcase is not yet available. From past experience I know that during
creation of a testcase from this crash scenario, the problem tends to slip away
in the simplification process of creating the testcase. So I hope the problem
can be diagnosed and fixed from the stacktrace information alone.

talkback 4156951 filed on the 17th.  The stack for that talkback is:

     nsDOMWindowList::GetLength  
[d:\builds\seamonkey\mozilla\dom\src\base\nsDOMWindowList.cpp, line 107]
     GlobalWindowImpl::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1699]
     XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
     XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027]
     XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1299]
     js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790]
     js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881]
     js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2503]
     js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2578]
     js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806]
     nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1195]
     nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
     PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
     SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
     nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
     nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1737]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3457]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
     nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 4680]
     GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 687]
     nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3231]
     nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 487]
     PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6051]
     PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5979]
     nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2043]
     nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
     nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1863]
     HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
     nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
     nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
     nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4903]
     nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3734]
     nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
     KERNEL32.DLL + 0x3663 (0xbff73663)  
     KERNEL32.DLL + 0x22894 (0xbff92894)

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Please don't plus bugs.  Bringing this down to a nomination of nsbeta1 and
sending to DOM 0.  Also nominating for a release in the past is a bit silly, so
nominating for 1.0.

Comment 2

[timeless]

Attachment: user error (or xpconnect), please provide the js script

my money says aLength == 0.

Comment 3

[bht237]

New talkback incident TB4246433Z filed on 2002-03-20.
Could someone please add it to this bug.
Many thanks.

Comment 4

[bht237]

New talkback incident TB4250687K filed on 2002-03-20.
It appears I can get 3 different crash locations:
GKCONTENT.DLL, JSDOM.DLL and XPCOM.DLL
Could someone please add it to this bug.
Many thanks.

Comment 5

[bht237]

New talkback incident TB4251527E filed on 2002-03-20.
It appears I can get 4 different crash locations:
GKCONTENT.DLL, JSDOM.DLL, XPCOM.DLL and <unknown>
Could someone please add it to this bug.
Many thanks.

Comment 6

[bht237]

Attachment: Testcase 1 (zip file)

This testcase repoduces the crash in GKCONTENT.DLL, 1 out of the 4 possible
crashes. Instructions how to set it up are included in one of the files.
I wish you all the best with this.

Comment 7

[bht237]

Changing priority to match bug 131841, which is the same issue but with other
stack traces and could not be reproduced with its own testcase.

IMHO it would be ideal to solve this case without delay after the experience
with bug 131841 since Sept 2001 and the fact that I came across 4 different
crashes when I wrote the testcase.

Comment 8

[bht237]

This bug would benefit from a hosted version of the testcase so that others can
confirm it. Currently the testcase is in an attached zip file.
Any help from someone who can modify and upload the files to a conventional and
a secure server would be highly appreciated.

Comment 9

[bht237]

Symptoms have changed. Refer to talkback TB4371676E
Testcase 1 is no longer reproducing at my end. Need new testcase if required.
The change was probably caused by the fix of bug 131725.

Comment 10

[Jay Patel [:jay]]

Confirming bug to new and adding reporters Talkback incidents.  Here are his
incidents in the order he has posted them in this bug:

 Incident ID 4246433   
Stack Signature  nsEventStateManager::ResetBrowseWithCaret 6a949de0
Trigger Time 2002-03-19 22:11:02
Email Address [e-mail]
URL visited
Build ID 2002031711
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments Transition from secure to normal site Refer to:
http://bugzilla.mozilla.org/show_bug.cgi?id=131841
Stack Trace
nsEventStateManager::ResetBrowseWithCaret
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 4521]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 508]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6051]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5979]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2043]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1863]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4903]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3734]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
KERNEL32.DLL + 0x3663 (0xbff73663)
KERNEL32.DLL + 0x22894 (0xbff92894) 

========================================================================
 Incident ID 4250687   
Stack Signature  nsCOMPtr_base::assign_with_AddRef 1dbf7d71
Trigger Time 2002-03-20 01:54:12
Email Address [e-mail]
URL visited
Build ID 2002031711
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments Refer to http://bugzilla.mozilla.org/show_bug.cgi?id=131841 During
work attempting to make a testcase
Stack Trace
nsCOMPtr_base::assign_with_AddRef
[d:\builds\seamonkey\mozilla\xpcom\glue\nsCOMPtr.cpp, line 74]
PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6383]
PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6383]
PresShell::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5053]
nsDocument::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3421]
nsHTMLDocument::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line
1496]
nsDOMWindowList::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsDOMWindowList.cpp, line 103]
GlobalWindowImpl::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1699]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027]
XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1299]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881]
js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2503]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2578]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806]
nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1195]
nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1737]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3457]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 4680]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 687]
nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3231]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 487]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6051]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5979]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2043]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1863]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4903]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3734]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
KERNEL32.DLL + 0x3663 (0xbff73663)
KERNEL32.DLL + 0x22894 (0xbff92894) 

====================================================
 Incident ID 4251527   
Stack Signature  0x025e278f ce1a1fa1
Trigger Time 2002-03-20 02:41:36
Email Address [e-mail]
URL visited
Build ID 2002031711
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments Refer to http://bugzilla.mozilla.org/show_bug.cgi?id=131841 while
working on a testcase
Stack Trace
0x025e278f
PresShell::ProcessReflowCommands
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6383]
PresShell::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5053]
nsDocument::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3421]
nsHTMLDocument::FlushPendingNotifications
[d:\builds\seamonkey\mozilla\content\html\document\src\nsHTMLDocument.cpp, line
1496]
nsDOMWindowList::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsDOMWindowList.cpp, line 103]
GlobalWindowImpl::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1699]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027]
XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1299]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881]
js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2503]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2578]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806]
nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1195]
nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1737]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3457]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 4680]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 687]
nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3231]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 487]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6051]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 5979]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2043]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1863]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4903]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3734]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
KERNEL32.DLL + 0x3663 (0xbff73663)
KERNEL32.DLL + 0x22894 (0xbff92894) 

==================================================================
 Incident ID 4371676   
Stack Signature  nsDOMWindowList::GetLength 141b88ab
Trigger Time 2002-03-22 20:12:00
Email Address [e-mail]
URL visited
Build ID 2002032211
Product ID MozillaTrunk
Platform
Operating System Win32
Module
Trigger Reason Access violation
User Comments bug 131841
Stack Trace
nsDOMWindowList::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsDOMWindowList.cpp, line 107]
GlobalWindowImpl::GetLength
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1705]
XPTC_InvokeByIndex
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp,
line 106]
XPCWrappedNative::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, line 2027]
XPC_WN_GetterSetter
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp,
line 1299]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 790]
js_InternalInvoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 881]
js_GetProperty [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 2503]
js_Interpret [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2578]
js_Invoke [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 806]
nsXPCWrappedJSClass::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, line 1195]
nsXPCWrappedJS::CallMethod
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 430]
PrepareAndDispatch
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 117]
SharedStub
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp,
line 139]
nsEventListenerManager::HandleEventSubType
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1218]
nsEventListenerManager::HandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventListenerManager.cpp, line
1737]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3457]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 3438]
nsXULElement::HandleChromeEvent
[d:\builds\seamonkey\mozilla\content\xul\content\src\nsXULElement.cpp, line 4686]
GlobalWindowImpl::HandleDOMEvent
[d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 693]
nsDocument::HandleDOMEvent
[d:\builds\seamonkey\mozilla\content\base\src\nsDocument.cpp, line 3232]
nsEventStateManager::PreHandleEvent
[d:\builds\seamonkey\mozilla\content\events\src\nsEventStateManager.cpp, line 487]
PresShell::HandleEventInternal
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6078]
PresShell::HandleEvent
[d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6006]
nsViewManager::HandleEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 2064]
nsView::HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 306]
nsViewManager::DispatchEvent
[d:\builds\seamonkey\mozilla\view\src\nsViewManager.cpp, line 1876]
HandleEvent [d:\builds\seamonkey\mozilla\view\src\nsView.cpp, line 83]
nsWindow::DispatchEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 869]
nsWindow::DispatchWindowEvent
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 886]
nsWindow::DispatchFocus
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 4903]
nsWindow::ProcessMessage
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3734]
nsWindow::WindowProc
[d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 1131]
KERNEL32.DLL + 0x3663 (0xbff73663)
KERNEL32.DLL + 0x22894 (0xbff92894) 

BHT: Those are all different stacks...did you crash the first 3 times with the
testcase attached?  What exactly did you do to get the 4th crash? 

Comment 11

[bht237]

jpatel,
Thanks for attaching the stack traces.
The last 4 traces were added in the sequence in which I gradually reduced the
complexity from the real sites to Testcase 1 <-> 4th crash.
In a later build that testcase no longer reproduced but the original crash 1
still does. Therefore I have to make a new testcase unless of course you can see
from the 1st crash where the problem is and how to fix it.
It takes me about 1 day of work to make such a testcase because of the
complexity and the different sites I have to work on. I am always trying to
provide the least complex testcase possible so you don't have to wrestle with
other unrelated garbage but this time this approach failed because I probably
hit another bug that was fixed later.

I can say that the involved scripts are rather defensive and well-behaved and
there are no errors with other browsers such as IE and Netscape 4. I would like
to make a new testcase but I am sick and later I will be committed at work. I
could still download a new build after any patches and check.

Comment 12

[Johnny Stenback (:jst)]

jband, dbradley, why is XPConnect passing a bad pointer as the out param
argument here?

Comment 13

[John Bandhauer]

I tried but was unable to reproduce this on Win2000 using the test in the
previous bug (and a bunch of other similar attempts). I don't have a secure
server handy in order to setup the testcase attached here. As mentioned above,
it would be very helpful if someone could set that case up on some servers so
that we can reprouce the bug against it.

There's no way xpconnect would be screwing up that out param without something
else very strange going on. Perhaps there is some general memory corruption
going on here (I see other sorts of stacks above). Otherwise, it might be that
xpconnect does not have the interface pointer to the window that it thinks it
has (and is trying to call some other method in a similar slot in the wrong
vtbl). Being able to reproduce this in a debugger would allow us to use
DumpJSStack in order to find out exactly what JS code is running. And inspection
in the debuger would allow us to tell whether or not it really is trying to call
that method on that class.

Comment 14

[bht237]

I am afraid Testcase 1 does no longer reproduce either. Please don't waste your
valuable time unnecessarily on this testcase.

It would be an incredibly useful thing if until I am back again with a new
testcase someone would be able to provide a secure server for testing.
Thanks John that you mentioned this. A test certificate would be o.k. However,
server generated IDs in the attachments on both sides such as in bugzilla would
make testing too difficult because we need 2 URLs that refer to each other both
ways.

Comment 15

[bht237]

Attachment: Testcase 2. Complete set of normal and secure HTML in zip file.

New Testcase 2 has been crashing in 3 different modules on my Win95 comp in
frequency order:
- JSDOM.DLL
- <unknown>
- XPCOM.DLL

It needs a secure server and 2 files must be configured to run it:
- mainbutton.htm
- secureframeset.htm

The testcase is not as minimal as Testcase 1 which was too narrow in scope.
Some code might not be relevant e.g. I don't think we need as many windows for
crashing, but I am not guessing what code is actually crashing the browser.

I think this is very exciting and I am hoping that this testcase will help to
nail down and fix the problem soon. Good luck!

Comment 16

[bht237]

Testcase 2 is consistently crashing with the latest 2002040803 build.
Is there anything I can do e.g. upload the testcase to a Mozilla secure area?

Comment 17

[David Bradley]

If you or someone could get these onto a web server that would be great. I
currently don't have a system I could throw these onto at the moment.

Comment 18

[bht237]

David,
I downloaded Apache and mod_ssl from www.apache.org and installed both on a
redhat machine on our intranet. That is really easy and takes only 1/2 to 1 hour.
The bug definitely reproduces with the built-in default certificate or -
whatever that is - so I didn't have to do anything other than to copy the files
into the document root directory.
It's quite handy to have such a server for development and a bit of fun also.
Maybe you find that useful, too.

Comment 19

[bht237]

cc-ing jkeiser because of the involvement of frames on both sides (could not
reproduce without frames). Hope this helps.

Restored nsbeta1+ keyword as it was added by brendan to bug 102341 which has
been closed for technical or workflow reasons. This bug is in reality a clone of
bug 102341 and should be treated the same.

Brendan, I hope I did this right.

It would be good if someone could copy the milestone - I can't see why this
should be lost. Please correct me if I am wrong.

Comment 20

[Johnny Stenback (:jst)]

bht, only Netscape managers are allowed to add the nsbeta1+ keyword, to nominate
a bug for nsbeta1, add the nsbeta1 keyword (no +).

Comment 21

[Brendan Eich [:brendan]]

Let's see what the ADT does, and perhaps EDT will topembed+; I'm preapproving
anyone who can help to work on this for mozilla1.0.

/be

Comment 22

[Judson Valeski]

How reproducible is the test case (does anyone have the test case hosted so this
can be tested)? I transition from ssl->non-ssl and back and forth all the time.

Comment 23

[David Bradley]

From looking at the talkback incidents with similar stacks it looks to me as if
mDocShellNode is null in the call of nsDOMWindowList::GetLength:

http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsDOMWindowList.cpp#106
Don't know if that will spark any inspirations.

I too have not had any problems transition between HTTP and HTTPS. I haven't
tried the test case, but I know the sites I was going between both had frames. I
wasn't transitioning via a link, though.

Comment 24

[bht237]

The testcase reproduces 100% for me and others with different OSs e.g. Win98,
WinXP. I can use Netscape 6.1, 6.2, latest Mozilla 1.0 branch, no difference.
The only dependency I could imagine is that all these warning dialogs are turned
on as per default so you might want to delete your profile for that.
Regarding the hosting I have asked various ISPs, even Verisign but they all did
not reply.
I am pretty sure that this needs the transition between SSL and normal to reproduce.

Comment 25

[bht237]

Still crashing in:
Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.0rc2) Gecko/20020510
Talkback ID: TB6191404E

Comment 26

[Hampton Maxwell]

Uploaded testcase to https://polaris.101freeway.com/mozilla/secureframeset.htm
The certificate is expired, but that should not matter.

Reporter, does this crash appear with a simpler testcase that doesn't involve
all this javascript stuff?  It doesn't apppear that the 3 files other than
goback.htm on the normal http server are ever supposed to get loaded.

Comment 27

[bht237]

Thanks Hampton for configuring and uploading this to your secure server!

The start URL is:

http://www.xsta.cc/mozilla/bug131841/index.html

To answer your question, Mozilla DOES crash with any number of different
testcase modifications/variations, including less script and a smaller number of
windows.

However the reproducibility suffers with simplification and that has caused some
delay in the progress of this bug.

All files get loaded before the crash when you start at index.html.

Thanks again.

Comment 28

[John Bandhauer]

Thanks for setting this up!

I did manage to reproduce this. As noted above, the pref about notification of
entering and leaving secure sites apparently still needs to be set on. Also, I
tried a few times to reproduce this with no luck until I thought to turn back on
the pref that allows popups during onload etc. I believe that having these prefs
on is the default, but lots of us turn them off to avoid the additional modal
dialogs and popups. But, they seem to be required to reproduce the crash.

The crash I see is the one with this stack:

nsCOMPtr<nsIRequest>::assign_assuming_AddRef(nsIRequest * 0x00000000) line 472 +
3 bytes
nsCOMPtr<nsIRequest>::assign_with_AddRef(nsISupports * 0x00000000) line 915
nsCOMPtr<nsIRequest>::operator=(nsIRequest * 0x00000000) line 585
PresShell::RemoveDummyLayoutRequest() line 6628
PresShell::DoneRemovingReflowCommands() line 6577
PresShell::ProcessReflowCommands(int 0x00000000) line 6428
PresShell::FlushPendingNotifications(PresShell * const 0x045250c8, int
0x00000000) line 5178
nsDocument::FlushPendingNotifications(nsDocument * const 0x045f6db0, int
0x00000001, int 0x00000000) line 3602

The problem is that the PresShell instance has already been released while we
are still running code in it and setting its mDummyLayoutRequest member to nsnull.

It looks to me like in nsDocument::FlushPendingNotifications we ought to be
using a kungfuDeathGrip on the shell that we use at the bottom of the method to
call shell->FlushPendingNotifications. Holding an additional ref looks to be
required while this code runs.

There may be other implications around the members of mPresShells[] getting
released prematurely. I don't know.

I did put in a quick hack to hold a reference on the PresShell at that location
and tried again. It then crashed in nsDOMWindowList::GetLength (see the first
stack in this bug). In this case mDocShellNode == nsnull at the point where it
calls mDocShellNode->GetChildCount. Note that this is inside a
'if(mDocShellNode)' block. But, apparently doc->FlushPendingNotifications has
resulted in the mDocShellNode member getting nulled out. Maybe another
'if(mDocShellNode)' block is required here. Of maybe a local nsCOMPtr to hold an
additional ref. I don't know. I do see that this flushing and then using the
mDocShellNode member is common pattern here. Someone with more clues about this
code than I will have to decide the right way to fix it. Whatever the fix we
need to make sure that the similar cases are done correctly too - whether we see
crashes now or not.

But, anyway, it looks like the hosted testcase makes this easy enough to
reproduce - just set your prefs to to warn on entering and exiting secure sites
and don't suppress popups and you should be able to make it crash too.

Remember that most people will be using those pref defaults - so let's not
assume that this is an unlikely crash.

Comment 29

[Johnny Stenback (:jst)]

Attachment: Proposed fix.

Thanks jband for looking into this one.

This fix adds kungFuDeathGrip's that keeps the presshell alive around calls to
methods that might end up destroying the presshell, this also makes
nsDOMWindowList safe against flushes that end up zeroing out mDocShellNode,
even if I didn't see a crash due to that (but it could happen, and apparently
has).

Comment 30

[Johnny Stenback (:jst)]

This should be a 100% safe fix, and IMO we should try to push this for mozilla1.0.

Comment 31

[Jay Patel [:jay]]

Adding topcrash+ keyword per jband's comment #28, where he says, "Remember that
most people will be using those pref defaults - so let's not assume that this is
an unlikely crash."

Since this crash is showing up under various stack signatures and has the
potential to be topcrash, it wouldn't hurt to get this one fixed.  

Adding  [@ nsCOMPtr_base::assign_with_AddRef] [@ nsDOMWindowList::GetLength] to
summary for tracking (since those are the 2 stack signatures jband was able to
reproduce this crash with).

Comment 32

[scottputterman]

please get this reviewed and super reviewed, checked into the trunk and verified.

Comment 33

[Johnny Stenback (:jst)]

Attachment: Better fix, hold strong references to preshells while making calls on a presshell.

Comment 34

[Johnny Stenback (:jst)]

Attachment: Better fix, hold strong references to preshells while making calls on a presshell.

Comment 35

[vidur (gone)]

Comment on attachment 84111 [details] [diff] [review]
Better fix, hold strong references to preshells while making calls on a presshell.

sr=vidur

Comment 36

[Brendan Eich [:brendan]]

Comment on attachment 84111 [details] [diff] [review]
Better fix, hold strong references to preshells while making calls on a presshell.

r/sr=[e-mail], and this is wanted for 1.0rc3 -- look for approval
soon, pls. get it on the trunk sooner.

/be

Comment 37

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

     for (i = 0; i < count; i++) {
-      nsIPresShell* shell = NS_STATIC_CAST(nsIPresShell*, mPresShells[i]);
+      nsCOMPtr<nsIPresShell> shell =
+        NS_STATIC_CAST(nsIPresShell*, mPresShells[i]);
+
       if (shell) {
         shell->FlushPendingNotifications(aUpdateViews);
       }

Could |shell->FlushPendingNotifications(aUpdateViews);| end up removing the 
shell from mPresShells? If so you need to modify the loop more to get it 
working. If not, r=sicking

Comment 38

[bht237]

A comment on the side:
The basic process that the testcase of this bug is based on breaks if the new
preferences option "Open unrequested windows" is unchecked.
Please refer to bug 145372.
IMHO this new bug should be fixed soon to avoid future headaches i.e. to make
the lives of Mozilla and Netscape engineers a little easier.

Comment 39

[Johnny Stenback (:jst)]

Sicking, yeah, those loops are bad, but there's never more than one presshell in
those arrays, so I won't bother fixing the loops. At some point we should just
rip out the whole notion of there possibly being more than one presshell per
document, that just won't happen. Thanks for the reviews, checking in on the
trunk now.

Comment 40

[Johnny Stenback (:jst)]

Fix checked in on the trunk.

Comment 41

[scottputterman]

adding adt1.0.0+.  Please get drivers approval and then check into the 1.0 branch.

Comment 42

[Dawn Endico]

Comment on attachment 84111 [details] [diff] [review]
Better fix, hold strong references to preshells while making calls on a presshell.

a=chofmann,brendan
please check in to 1.0 branch asap to get this in rc3.

Comment 43

[Johnny Stenback (:jst)]

Fixed on branch too.

Comment 44

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

jst: iirc there is more then one presshell for a document during printing, but 
i guess that can be handled some other way

Comment 45

[Johnny Stenback (:jst)]

Yes, that's true, but we don't need to do it that way...

Comment 46

[Prashant Desale]

Tested with Testcase 2 provided by  [e-mail].
verified1.0.0 on 05-22-18-1.0.0 & also Verified on trunk on 05-23-08-trunk.

The only difference I saw in branch & trunk is that branch does not issue 
security warning while leaving the secure site & going to normal site.

Crash is fixed though.

Comment 47

[bht237]

Netscape 7.0 PR1 crashes on the testcase. Not a surprise probably for those who
know from where PR1 was built but I don't know the details of this, sorry.