115944 - Crash in XPCWrappedNative::InitTearOff

Status: RESOLVED INCOMPLETE

(Core :: XPConnect, defect, P1)

Description

[lchiang]

Crash in XPCWrappedNative::InitTearOff

Win2K build, 2001-12-17-06-trunk

I cannot reproduce this crash again, but I wanted to log this bug to include the
stack trace.  Hopefully, this is a bug that may be able to be fixed by putting
in some defensive code or null pointer checks.

Mainly, I had just clicked on a bug link in mail and the browser window appeared
and the bug report was loading in the browser window.  Then, the crash occurred.

Stack trace to follow.  I looked at Talkback reports and didn't see other
reports at this signature.

Comment 1

[lchiang]

Attachment: stack trace - incident report 650020

Comment 2

[David Bradley]

I haven't looked at the talkback data, but do you know for sure this was a null
pointer? From what I see and experimented with, it's nearly impossible to get to
this location this way with a null pointer. More likely, I think, the interface
was reclaimed before it was time. This should be fun to figure out.

Comment 3

[lchiang]

No, I do not know that a null pointer check would fix this.  I was only hoping
that was the case when I filed this report.  I don't have the reproducible
steps, unfortunately.

Let me cc: talkback staff to make sure that there aren't other reports with this
signature.  If so, may offer more clues.

Comment 4

[David Bradley]

Ok, that's fine. I looked back at the Talkback incident. I confirmed that it
looks like a dead interface is being accessed. The pointer itself is not null
but when it goes to do the vtable lookup it gets the null pointer.

I looked through the other threads. Nothing else seems to be going on at the
time of the crash either. There's something amiss here. I'll see if I can see
any way the interface could have gotten deleted.

Comment 5

[David Bradley]

I'm seeing about 13 Talkback incidents including lchiang's that appear to be
related to this bug. That's about one a day over the past two weeks. Doesn't
appear to be any one action causing this.

Adding crash, priority, and target.

Comment 6

[lchiang]

When I get a chance, I'll try to look at the other reports and see if any
comments lead me to some reproducible set of steps.  Did you search the talkback
database for XPCWrappedNative::InitTearOff stack signature?  

Comment 7

[David Bradley]

There wasn't too much there in the way of comments. Two sites were listed and I
had no problems. I figure this is some edge case tripped up by threading issues
or some obscure path. It's not happening a lot, but the crashes are fairly
consistent in nature, failing at aInterface->GetIID call or failing when
accessing the the nsIID returned by that call. Both point to deleted or
corrupted object.

As far as the Talkback search, yes, that's what I searched for. What's
interesting is that I've found two ways into Talkback. One is
http://climate/main which gives a fairly hefty nice looking page where you have
the Fast Find link. The other is http://climate which is a more spartan page.
Fast Find reports no incidents for this stack trace, while going to
http://climate and filling in the field there for the stack brings back the 13
incidents. I can put in the incident numbers via climate/main and it finds those.

Comment 8

[Shiva Thirumazhusai]

Lisa: Sorry we couldn't respond earlier. I am cc'ed into way too many bugs. 

http://climate is our simple view of the query engine.(faster)
http://climate/main came with the talkback software.

Comment 9

[David Bradley]

Moving to 0.9.9

Comment 10

[David Bradley]

I'm not any closer to tracking this one down. It's very sporadic, sometimes not
appearing for 5 days in talkback. It needs to be
addressed, but I doubt it will make it before 0.9.9 deadline.

Comment 11

[David Bradley]

retargetting to post 1.0 mozilla again

Comment 12

[David Bradley]

Retargetting to the proper post 1.0 milestone (really this time)

Comment 13

[David Bradley]

Just an update. There were 3 crashes on 2/19, 1 on 2/18, another on 2/15 and
then it never happened since 2/4. Going to keep an eye on it, keeping fingers
crossed that this might go away with the 2/19 builds. Another non-reproduceable
bug that was more frequent looks like it may have gotten fixed in that time
frame. Don't know if they might be related. Looks like it will be a couple of
weeks before it may be safe to say this is something not to worry about.

Comment 14

[lchiang]

"There were 3 crashes on 2/19, 1 on 2/18, another on 2/15 and
then it never happened since 2/4."

Do you mean "12/19, 12/18, and 12/15"?

I have not seen this bug in a while so it may be safe to say it has reduced in
frequency (harder to run into).

I am ok with this new target milestone since this bug (crash) has reduced in
scope.  Thanks.

Comment 15

[David Bradley]

Moving out to 1.3. If this needs to be in before 1.3 please comment.

Comment 16

[David Bradley]

Moving to 1.4 Alpha

Comment 17

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 18

[David Bradley]

Downgrading severity, this still happens, but it's very infrequent. Some
incidents have screwy stacks. I really think the source of this problem is
outside of XPConnect, but have no idea where. I see two instances, one where
XPConnect is trying to convert a COM pointer coming in as a parameter which
isn't valid, and the other has a flaky stack, XPC_WN_GetterSetter calling
XPCWrappedNative::CallMethod, which can't happen.

Comment 19

[David Bradley]

Moving out

Comment 20

[David Bradley]

Moving out

Comment 21

[Wayne Mery (:wsmwk)]

still see on trunk, but with different stack then comment 1.
no crashes though for 3 weeks - since 2008020500 build - maybe that's a good sign?

bp-2dd659f3-e1c7-11dc-802b-001a4bd43ef6

0  	XPCWrappedNative::InitTearOff(XPCCallContext&, XPCWrappedNativeTearOff*, XPCNativeInterface*, int)  	 mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:1567
1 	XPCWrappedNative::FindTearOff(XPCCallContext&, XPCNativeInterface*, int, unsigned int*) 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:1519
2 	XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, int, XPCWrappedNative**) 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:329
3 	XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, int, XPCWrappedNative**) 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:407
4 	XPCConvert::NativeInterface2JSObject(XPCCallContext&, nsIXPConnectJSObjectHolder**, nsISupports*, nsID const*, JSObject*, int, int, unsigned int*) 	mozilla/js/src/xpconnect/src/xpcconvert.cpp:1106
5 	XPCConvert::NativeData2JS(XPCCallContext&, long*, void const*, nsXPTType const&, nsID const*, JSObject*, unsigned int*) 	mozilla/js/src/xpconnect/src/xpcconvert.cpp:481
6 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2426
7 	XPC_WN_GetterSetter(JSContext*, JSObject*, unsigned int, long*, long*) 	mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1502
8 	js_Invoke 	
9 	js_InternalInvoke 	
10 	js_InternalGetOrSet 	
11 	js_NativeGet 	
12 	js_GetProperty 	
13 	js_Interpret 	
14 	js_Invoke 	
15 	nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) 	mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1473
16 	nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) 	mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp:556
17 	PrepareAndDispatch 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114
18 	SharedStub 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141
19 	nsEventListenerManager::HandleEventSubType(nsListenerStruct*, nsIDOMEventListener*, nsIDOMEvent*, nsISupports*, unsigned int) 	mozilla/content/events/src/nsEventListenerManager.cpp:1081

bp-3853abc2-db13-11dc-914b-001a4bd43ed6

0  	XPCWrappedNative::InitTearOff(XPCCallContext&, XPCWrappedNativeTearOff*, XPCNativeInterface*, int)  	 mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:406
1 	XPCWrappedNative::FindTearOff(XPCCallContext&, XPCNativeInterface*, int, unsigned int*) 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:1516
2 	XPCWrappedNative::GetNewOrUsed(XPCCallContext&, nsISupports*, XPCWrappedNativeScope*, XPCNativeInterface*, int, XPCWrappedNative**) 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:488
3 	XPCConvert::NativeInterface2JSObject(XPCCallContext&, nsIXPConnectJSObjectHolder**, nsISupports*, nsID const*, JSObject*, int, int, unsigned int*) 	mozilla/js/src/xpconnect/src/xpcconvert.cpp:1105
4 	XPCConvert::NativeData2JS(XPCCallContext&, long*, void const*, nsXPTType const&, nsID const*, JSObject*, unsigned int*) 	mozilla/js/src/xpconnect/src/xpcconvert.cpp:479
5 	nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) 	mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp:1341
6 	PrepareAndDispatch 	mozilla/xpcom/reflect/xptcall/src/md/unix/xptcstubs_ppc_rhapsody.cpp:182
7 	SharedStub 	
8 	nsEventListenerManager::HandleEventSubType(nsListenerStruct*, nsIDOMEventListener*, nsIDOMEvent*, nsISupports*, unsigned int) 	mozilla/content/events/src/nsEventListenerManager.cpp:1097
9 	nsEventListenerManager::HandleEvent(nsPresContext*, nsEvent*, nsIDOMEvent**, nsISupports*, unsigned int, nsEventStatus*) 	mozilla/content/events/src/nsEventListenerManager.cpp:1211
10 	nsEventTargetChainItem::HandleEvent(nsEventChainPostVisitor&, unsigned int) 	mozilla/content/events/src/nsEventDispatcher.cpp:206
11 	nsEventTargetChainItem::HandleEventTargetChain(nsEventChainPostVisitor&, unsigned int, nsDispatchingCallback*) 	mozilla/content/events/src/nsEventDispatcher.cpp:237
12 	nsEventDispatcher::Dispatch(nsISupports*, nsPresContext*, nsEvent*, nsIDOMEvent*, nsEventStatus*, nsDispatchingCallback*) 	mozilla/content/events/src/nsEventDispatcher.cpp:479
13 	nsEventDispatcher::DispatchDOMEvent(nsISupports*, nsEvent*, nsIDOMEvent*, nsPresContext*, nsEventStatus*) 	mozilla/content/events/src/nsEventDispatcher.cpp:537
14 	nsEventListenerManager::DispatchEvent(nsIDOMEvent*, int*) 	mozilla/content/events/src/nsEventListenerManager.cpp:1340
15 	nsDOMEventRTTearoff::DispatchEvent(nsIDOMEvent*, int*) 	mozilla/content/base/src/nsGenericElement.cpp:1009
16 	XUL@0x855a7c 	
17 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2347
18 	XPC_WN_CallMethod(JSContext*, JSObject*, unsigned int, long*, long*) 	mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp:1467
19 	js_Invoke 	mozilla/js/src/jsinterp.c:1356
20 	js_Interpret 	mozilla/js/src/jsinterp.c:4173
21 	js_Invoke 	mozilla/js/src/jsinterp.c:1376
22 	js_InternalInvoke 	mozilla/js/src/jsinterp.c:1432
23 	js_InternalGetOrSet 	mozilla/js/src/jsinterp.c:1495
24 	js_SetProperty 	mozilla/js/src/jsobj.c:3770
25 	js_Interpret 	mozilla/js/src/jsinterp.c:3898
26 	js_Invoke 	mozilla/js/src/jsinterp.c:1376
27 	js_InternalInvoke 	mozilla/js/src/jsinterp.c:1432
28 	js_InternalGetOrSet 	mozilla/js/src/jsinterp.c:1495

Comment 22

[Jesse Ruderman on Windows]

Given that David Bradley couldn't figure this out after looking at many stacks, I'm marking this bug as incomplete.