199320 - crashes in composer after opening files or when switching views [@ XPCWrappedNative::GetNewOrUsed()]

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[sairuh (rarely reading bugmail)]

found using 2003032608 on linux rh8.0. so far unable to repro on win2k or mac os
x. tricky trying to get a good set of steps for this, but i ran into three
times, and kin saw it on a fresh debug.

1. launch the app with a browser window.
2. open a composer window --i used ctrl+4 to do so.
3. click on the open button in the composer toolbar.
4. pick an existing file to edit.
5. after the file opens, click somewhere near the top.
6. click btwn the html source and normal views.

results: eventually the app will crash. tb below.

Incident ID 18488620
Stack Signature 	0x08b9b8c0 0ece936f
Product ID 	MozillaTrunk
Build ID 	2003032608
Trigger Time 	2003-03-26 10:40:37
Operating System 	Linux 2.4.18-24.8.0
User Comments 	clicked html source tab in composer
Trigger Reason 	SIGILL: Illegal Instruction: (signal 4)
Source File Name 	
Trigger Line No. 	
Stack Trace 	
0x08b9b8c0
netscape-bin + 0x277f5 (0x0806f7f5)
XPCWrappedNative::GetNewOrUsed()
[/builds/client/linux22/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 855]
XPCConvert::NativeInterface2JSObject()
[/builds/client/linux22/seamonkey/mozilla/js/src/xpconnect/src/xpcconvert.cpp,
line 1060]
XPCConvert::NativeData2JS()
[/builds/client/linux22/seamonkey/mozilla/js/src/xpconnect/src/xpcconvert.cpp,
line 461]
nsXPCWrappedJSClass::CallMethod()
[/builds/client/linux22/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1223]
nsXPCWrappedJS::CallMethod()
[/builds/client/linux22/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 428]
PrepareAndDispatch()
[/builds/client/linux22/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_gcc_x86_unix.cpp,
line 100]
nsControllerCommandManager::IsCommandEnabled()
[/builds/client/linux22/seamonkey/mozilla/embedding/components/commandhandler/src/nsControllerCommandManager.cpp,
line 126]
nsBaseCommandController::IsCommandEnabled()
[/builds/client/linux22/seamonkey/mozilla/embedding/components/commandhandler/src/nsBaseCommandController.cpp,
line 118]
XPTC_InvokeByIndex()
XPCWrappedNative::CallMethod()
[/builds/client/linux22/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2023]
XPC_WN_CallMethod()
[/builds/client/linux22/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1292]
js_Invoke() [/builds/client/linux22/seamonkey/mozilla/js/src/jsinterp.c, line 843]
js_Interpret() [/builds/client/linux22/seamonkey/mozilla/js/src/jsinterp.c, line
2830]
js_Invoke() [/builds/client/linux22/seamonkey/mozilla/js/src/jsinterp.c, line 860]
js_InternalInvoke() [/builds/client/linux22/seamonkey/mozilla/js/src/jsinterp.c,
line 935]
JS_CallFunctionValue() [/builds/client/linux22/seamonkey/mozilla/js/src/jsapi.c,
line 3527]
nsJSContext::CallEventHandler()
[/builds/client/linux22/seamonkey/mozilla/dom/src/base/nsJSEnvironment.cpp, line
1068]
nsJSEventListener::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/dom/src/events/nsJSEventListener.cpp,
line 181]
nsEventListenerManager::HandleEventSubType()
[/builds/client/linux22/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1191]
nsEventListenerManager::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/content/events/src/nsEventListenerManager.cpp,
line 2190]
nsXULElement::HandleDOMEvent()
[/builds/client/linux22/seamonkey/mozilla/content/xul/content/src/nsXULElement.cpp,
line 3337]
PresShell::HandleDOMEventWithTarget()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6350]
nsButtonBoxFrame::MouseClicked()
[/builds/client/linux22/seamonkey/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp,
line 184]
nsButtonBoxFrame::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/layout/xul/base/src/nsButtonBoxFrame.cpp,
line 144]
PresShell::HandleEventInternal()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6318]
PresShell::HandleEventWithTarget()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6257]
nsEventStateManager::CheckForAndDispatchClick()
[/builds/client/linux22/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp,
line 2863]
nsEventStateManager::PostHandleEvent()
[/builds/client/linux22/seamonkey/mozilla/content/events/src/nsEventStateManager.cpp,
line 1857]
PresShell::HandleEventInternal()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6323]
PresShell::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6211]
nsViewManager::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/view/src/nsViewManager.cpp, line 2216]
nsView::HandleEvent()
[/builds/client/linux22/seamonkey/mozilla/view/src/nsView.cpp, line 308]
nsViewManager::DispatchEvent()
[/builds/client/linux22/seamonkey/mozilla/view/src/nsViewManager.cpp, line 1948]
HandleEvent() [/builds/client/linux22/seamonkey/mozilla/view/src/nsView.cpp,
line 83]
nsWidget::DispatchEvent()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWidget.cpp, line 1496]
nsWidget::DispatchWindowEvent()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWidget.cpp, line 1385]
nsWidget::DispatchMouseEvent()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWidget.cpp, line 1525]
nsWidget::OnButtonReleaseSignal()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWidget.cpp, line 1980]
nsWindow::OnButtonReleaseSignal()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWindow.cpp, line 1662]
nsWindow::HandleGDKEvent()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsWindow.cpp, line 1761]
dispatch_superwin_event()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,
line 1005]
handle_gdk_event()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsGtkEventHandler.cpp,
line 878]
libgdk-1.2.so.0 + 0x192d5 (0x4027d2d5)
libglib-1.2.so.0 + 0x1297e (0x402b297e)
libglib-1.2.so.0 + 0x12e59 (0x402b2e59)
libglib-1.2.so.0 + 0x130f4 (0x402b30f4)
libgtk-1.2.so.0 + 0xa86df (0x401b16df)
nsAppShell::Run()
[/builds/client/linux22/seamonkey/mozilla/widget/src/gtk/nsAppShell.cpp, line 336]
nsAppShellService::Run()
[/builds/client/linux22/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 479]
netscape-bin + 0x12451 (0x0805a451)
netscape-bin + 0x12cbb (0x0805acbb)
0x420158d4

Comment 1

[sairuh (rarely reading bugmail)]

so far i cannot repro this with the 2003.03.25.05 build.

Comment 2

[sairuh (rarely reading bugmail)]

...nor with 2003.03.25.17.

Comment 3

[sairuh (rarely reading bugmail)]

aha, i got this to occur in win2k. the tb report is similar to the linux one:

http://climate.netscape.com/reports/SingleIncidentInfo.cfm?dynamicBBID=18498246

the trick i found was with the file i had opened in composer. save the link
below (internal server), open it in composer, then just click near the top of
the editing region. results: crash.

http://hopey.mcom.com/tests/bigbookmarks2.html

Comment 4

[sairuh (rarely reading bugmail)]

more data: so far unable to repro on mac os x 10.2.4 (2003.03.26.15).

Comment 5

[Chris Casciano]

I'm seeing a very similar crash on a fair amount of file open attempts in
composer... OS X 2003032609... same file doesn't always crash, but the crash is
always after accepting a file open dialog:

Thread 0 Crashed:
 #0   0x23814100 in 0x23814100
 #1   0x001d971c in nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&,
nsID const&)
 #2   0x004375c4 in XPCWrappedNative::GetNewOrUsed(XPCCallContext&,
nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, XPCWrappedNative**)
 #3   0x00425f6c in XPCConvert::NativeInterface2JSObject(XPCCallContext&,
nsIXPConnectJSObjectHolder**, nsISupports*, nsID const*, JSObject*, unsigned*)
 #4   0x00425348 in XPCConvert::NativeData2JS(XPCCallContext&, long*, void
const*, nsXPTType const&, nsID const*, JSObject*, unsigned*)
 #5   0x00436b50 in nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned
short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)
 #6   0x001c52d4 in PrepareAndDispatch

Full trace:
http://placenamehere.com/Mozilla/crash_fileopen.txt

different bug? if so i'll file it... if not this bug should -> All/All

Comment 6

[sairuh (rarely reading bugmail)]

chris, i think it's be the same bug. thanks for the information!

Comment 7

[sairuh (rarely reading bugmail)]

i hoped this would be a one-off bug, but it's still occuring with today's build.
nominating.

Comment 8

[kinmoz]

I'm having a real hard time reproducing this problem on Win32 ... I did manage
to crash once after opening a file in composer, opening a new composer, closing
it, clicking in the first composer window and then clicking in a different
window, and back into composer.

The command it was asking enabled status about was "cmd_updateStructToolbar".

Comment 9

[kinmoz]

Cc'ing dbradley per brendan.

dbradley, it looks as if some isupports object is being deleted out from under
xpconnect, so the pv->val being passed into XPCConvert::NativeData2JS() from
XPCWrappedJSClass::CallMethod() points to garbage.

Is there an easy way to debug this stuff and find out what object that was?

In the meantime, I'll try backing out some checkins within sairuh's window
(03/25 5pm - 03/26 8am) to see if I can narrow down the culprit.

Comment 10

[kinmoz]

FYI, jkeiser told me on IRC that he managed to reproduce the crash with the
2003032508 build.

Comment 11

[John Keiser (jkeiser)]

Yep, I cannot reproduce in 2003032416 but I *can* reproduce in 2003032508.  This
is WinXP.

Comment 12

[Hermann Schwab]

Bug 199455 crash if loading local files or URLs into composer.

should be a DUPE of this one, contains some Talkback-IDs (Win98)

Comment 13

[David Bradley]

Attachment: Purify stack to the first sign of problems

This was an odd error. Sounds like something was allocated on the stack, and
then released. And then used by js_Execute. This eventually results in a crash
later on.

Comment 14

[David Bradley]

I caught it in the debugger and the key seems to be
nsBaseCommandController::IsCommandEnabled. The object pointed to by
mCommandRefCon appears to have been deleted.

Comment 15

[kinmoz]

The mCommandRefCon is an un-add-ref'd pointer to what should be the HTMLEditor.
It looks like we aren't nulling out the  ref con for one of the base command 
controllers when swapping in the new editor.

I verified that the ref con is indeed pointing to the old html editor that was
just destroyed.

Comment 16

[Simon Fraser [no longer active]]

Attachment: Don't set the editor as the refCon on JS controllers

This patch fixes the problem, which was that one of the controllers created in
JS kept a stale pointer to a deleted editor. This caused problems later when
xpconnecct tried to wrap that stale pointer.

Comment 17

[kinmoz]

Comment on attachment 118799 [details] [diff] [review]
Don't set the editor as the refCon on JS controllers

sr=[e-mail]

Comment 18

[Johnny Stenback (:jst)]

Should we not add protection core in the C++ code to prevent this crash if
someone makes a similar mistake in the future?

Comment 19

[Jim Booth]

Here are 5 additional talkback IDs from Composer Crashes on Build 
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.4a) Gecko/20030329 
Build ID 2003032908

These 3 happened just after loading the first page to edit
TB18625520M 
TB18625618W
TB18626734E

These 2 happened later while editing a page

TB18625585X
TB18626653H

Comment 20

[Asa Dotzler [:asa]]

Comment on attachment 118799 [details] [diff] [review]
Don't set the editor as the refCon on JS controllers

a=asa (on behalf of drivers) for checkin to 1.4a

Comment 21

[Kathleen :Brade]

-->sfraser since it's his patch

Comment 22

[Kathleen :Brade]

*** Bug 199455 has been marked as a duplicate of this bug. ***

Comment 23

[Simon Fraser [no longer active]]

Checked in.

Comment 24

[Johnny Stenback (:jst)]

Uh, please see my previous comment. I don't think this is enough to fix this
bug, the crash is still there waiting to happen. Or did I miss something here?

Comment 25

[Simon Fraser [no longer active]]

The API to set a controller refCon is not public. In addition, the burden of
clearing out the refCon when it goes stale lies on the same code that sets the
refCon in the first place. If someone writes JS that sets the refCon, they'll
have to write code to clear is as well. This is no different from how we drive
many other of our private.APIs from JS.

Comment 26

[sairuh (rarely reading bugmail)]

using 2003.04.01 comm trunk bits on win2k and linux rh8.0, i no longer get this
crash.

chris, do you see this on Mac OS X anymore?

Comment 27

[Chris Casciano]

No... I can't seem to reproduce this crash w/ 1.4a OS X... pages seem to open fine

Comment 28

[sairuh (rarely reading bugmail)]

hm, is 1.4a based on 2003.03.31 or 2003.04.01? because i think this fix would be
in 2003.04.01 and later...

anyhow, chris petersen just told me that he can no longer repro this on OS X
with today's build, so i'm marking this verified.