520554 - Crash [@ WrappedNativeMarker ]

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Carsten Book [:Tomcat]]

From the Topcrash statistics:

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.5.3&query_search=signature&query_type=exact&query=&date=&range_value=1&range_unit=weeks&do_query=1&signature=WrappedNativeMarker

seems to be a cross-platform (windows/mac) crash. Linux seems not affected. 

Can we get a url list for this crash ?

Comment 1

[Robert Sayre]

> Can we get a url list for this crash ?

ping

Comment 3

[Oleg Romashin (:romaxa)]

Here is the steps how to reproduce this on N900 with microb-1.9.2 engine
https://bugzilla.mozilla.org/show_bug.cgi?id=526483#c11

Comment 5

[Oleg Romashin (:romaxa)]

Reopen this bug, because bug 526483 was caused by non-mozilla code memory corruption.

Comment 6

[timeless]

Signature	WrappedNativeMarker
UUID	5ece3449-9fa6-4a59-8413-6542d2091110
Time 	2009-11-10 19:26:34.751415
Uptime	310
Product	Firefox
Version	3.5.3
Build ID	20090824101458
Branch	1.9.1
OS	Windows NT
OS Version	6.0.6000
CPU	x86
CPU Info	AuthenticAMD family 15 model 127 stepping 1
Crash Reason	EXCEPTION_ACCESS_VIOLATION
Crash Address	0x10
User Comments	
Processor Notes 	
Related Bugs

Crashing Thread
Frame 	Module 	Signature [Expand] 	Source
0 	xul.dll 	WrappedNativeMarker 	js/src/xpconnect/src/xpcwrappednativescope.cpp:506
1 	js3250.dll 	JS_DHashTableEnumerate 	js/src/jsdhash.cpp:724
2 	xul.dll 	XPCWrappedNativeScope::MarkAllWrappedNativesAndProtos 	js/src/xpconnect/src/xpcwrappednativescope.cpp:526
3 	xul.dll 	XPCJSRuntime::GCCallback 	js/src/xpconnect/src/xpcjsruntime.cpp:573
4 	mozcrt19.dll 	arena_dalloc 	obj-firefox/memory/jemalloc/src/jemalloc.c:4568
5 	js3250.dll 	js_GC 	js/src/jsgc.cpp:3698
6 	js3250.dll 	JS_TriggerOperationCallback 	
7 	xul.dll 	nsDocShell::QueryInterface 	docshell/base/nsDocShell.cpp:445
8 		@0x4f6fff 	

503 WrappedNativeMarker(JSDHashTable *table, JSDHashEntryHdr *hdr, uint32 number, void *arg)
506 ((Native2WrappedNativeMap::Entry*)hdr)->value->Mark(); 

class Native2WrappedNativeMap
{
public:
    struct Entry : public JSDHashEntryHdr
    {
        nsISupports*      key;
        XPCWrappedNative* value;
    };

This probably means hdr is 0x0, although i'm having some minor trouble convincing myself that i like this form of the math

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Need a blocking decision for mozilla-1.9.2

Comment 8

[chris hofmann]

floating between 270-344 crashes per day for oct/nov.

mostly on big releases.

distribution of all versions where the WrappedNativeMarker crash was found on 20091119-crashdata.csv
 198 Firefox 3.5.5
  79 Firefox 3.0.15
  12 Firefox 3.6b2
   8 Firefox 3.5.3
   5 Firefox 3.6b3
   5 Firefox 3.0.7
   4 Firefox 3.6b1

no regression visible here.

Comment 9

[Damon Sicore (:damons)]

Marking blocking1.9.2- to explicitly mark [CrashKill] bugs as either blocking or not.  If we can get a patch before RC, we should really consider taking it.

Comment 10

[Johnny Stenback (:jst)]

This is currently top crash #68, we should attempt to investigate this a bit deeper. Peter, wanna pull some minidumps and see what your shiny new IDA Pro has to say? :)

And based on timeless' comment, my thoughts are that it's more likely that "value" is null here than hdr, but I didn't dig too deep...

Comment 11

[Matthew Cline]

Happens with latest 3.7a5pre and the development version of the Vimperator addon, if you use Vimperator to do a text search and then move to the next search match ("/" to search and "n" to go to next match).  May need to hold down "n" for a little while for it to happen.

Example crashes:

bp-69ab503b-f4e2-4833-974a-473df2100506
bp-9477a3a2-99d3-4d56-9df0-0e9cf2100506
bp-b4b20b0c-5ffa-42fd-8929-e92712100506

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

This still a beta2 blocker, or more betaN?

Comment 13

[Johnny Stenback (:jst)]

Pushing out to betaN, but given the limited knowledge that we have about what's going on here we may not get to this for Firefox 4.

Comment 14

[Benjamin Smedberg]

I have this in recording.

Comment 15

[Benjamin Smedberg]

During GC:

((Native2WrappedNativeMap::Entry*)hdr)->value->Mark();

in Mark, we call if(HasProto()) GetProto()->Mark();

The XPCNativeWrapper is:
-		value	0x0747c4c0 {mRefCnt={...} mMaybeScope=0x00000000 mMaybeProto=0x00000000 ...}	XPCWrappedNative *
+		nsIXPConnectWrappedNative	{mIdentity=0x00000000 }	nsIXPConnectWrappedNative
+		mRefCnt	{mValue=0x00000001 }	nsAutoRefCnt
+		_cycleCollectorGlobal	{...}	XPCWrappedNative::cycleCollection
+		mMaybeScope	0x00000000 {gScopes=0x05a8b380 gDyingScopes=0x02bba500 mRuntime=??? ...}	XPCWrappedNativeScope *
+		mMaybeProto	0x00000000 {mScope=??? mJSProtoObject=??? mClassInfo={...} ...}	XPCWrappedNativeProto *
-		mSet	0x07dcd720 {mMemberCount=0x003e mInterfaceCount=0x8005 mInterfaces=0x07dcd724 }	XPCNativeSet *
		mMemberCount	0x003e	unsigned short
		mInterfaceCount	0x8005	unsigned short
-		mInterfaces	0x07dcd724	XPCNativeInterface * [1]
+		[0x0]	0x020e75e0 {mInfo={...} mName=0x020e63bc mMemberCount=0x8001 ...}	XPCNativeInterface *
+		mFlatJSObject	0x00000000 {map=??? classword=??? fslots=0x00000008 ...}	JSObject *
+		mScriptableInfo	0x05b4afc0 {mCallback={...} mShared=0x067c1660 }	XPCNativeScriptableInfo *
+		mFirstChunk	{mTearOffs=0x0747c4dc mNextChunk=0x07de9ba0 }	XPCWrappedNativeTearOffChunk
		mWrapperWord	0x00000000	long

So it's a !IsValid XPCNativeWrapper: are we only supposed to be marking valid wrappers? mMaybeScope is null, so IsTaggedScope is false, so HasProto is true (but mMaybeProto is NULL).

Comment 16

[Benjamin Smedberg]

Earlier in the same GC, we're hitting XPCWrappedNative::FlatJSObjectFinalized for this object, which nulls out mMaybeScope.

Earlier in that function it calls GetScope()->GetWrapperMap()->Remove(mFlatJSObject), but I'm stepping through JS_DHashTableOperate and I think that the entry is not found.

Comment 17

[Peter Van der Beken [:peterv]]

Benjamin: if you take a bug that's assigned to me please at least CC me (though I'd prefer if you'd check with me first before taking).

I have a similar crash in recording. It looks like the wrapper is removed from the hash correctly, but we somehow hit it during enumeration of the hash. (GetScope()->GetWrapperMap() is not the Native2WrappedNativeMap)

Comment 18

[Benjamin Smedberg]

Have at it! I thought you couldn't reproduce.

Comment 24

[chris hofmann]

I don't see any crashes for WrappedNativeMarker in the top 300 for b4 or early b5, and only this one crash for this signature in the last 3 weeks.  It was on 4.0b6pre on build 20100903040836 

http://crash-stats.mozilla.com/report/index/afc1b43c-4089-4122-b994-bda072100907

Comment 25

[bogas04]

http://crash-stats.mozilla.com/report/index/222c1bc4-1911-4074-b1bb-975782101016

Comment 26

[Logan Rosen [:Logan]]

http://crash-stats.mozilla.com/report/index/df48eb48-f037-44db-aa89-666da2101117

Comment 27

[Johnny Stenback (:jst)]

This is still around, but on the order of 2-4 crashes per day on trunk, which places it at #162 atm. I'm not convinced this needs to be a 2.0 blocker.

Comment 28

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

Need steps to reproduce. Can't block until we have more info.

Comment 29

[Scoobidiver (away)]

It's #46 top browser crasher w/o hangs in 17.0.1, #12 in 18.0b4, and #24 in 19.0a2.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=WrappedNativeMarker

Comment 30

[Alex Keybl [:akeybl]]

(In reply to Scoobidiver from comment #29)
> It's #46 top browser crasher w/o hangs in 17.0.1, #12 in 18.0b4, and #24 in
> 19.0a2.
> 
> More reports at:
> https://crash-stats.mozilla.com/report/list?signature=WrappedNativeMarker

Since this is spiking across multiple versions, Scoobidiver/KaiRo - can you look for actionable leads (correlations, URLs, etc.)? Thanks!

Comment 31

[Scoobidiver (away)]

(In reply to Alex Keybl [:akeybl] from comment #30)
> Scoobidiver/KaiRo - can you look for actionable leads (correlations, URLs, etc.)?
I had already checked correlations in the three channels for the last two days and there were no obvious correlations.

Comment 32

[Robert Kaiser]

Also nothing obvious in correlations:

137 	http://www.facebook.com/
101 	https://www.facebook.com/
79 	about:blank
22 	about:sessionrestore
19 	http://www.facebook.com/?ref=tn_tnmn
17 	about:home

Comment 34

[Alex Keybl [:akeybl]]

Longstanding crash, no actionable leads, nothing to do here unless peterv or jst know of any good next steps on the egr side.

Comment 35

[Scoobidiver (away)]

It's #20 browser crasher in 20.0.1, #53 in 21.0b5, and #55 in 22.0a2.

Comment 36

[Scoobidiver (away)]

It's #50 browser crasher in 22.0, #71 in 23.0b1, and #117 in 24.0a2 so no longer a top crash.

Comment 37

[Johnny Stenback (:jst)]

Cc:ing mccr8 here so he can keep his eyes out for this one too. Not much to go on here tho :(

Comment 38

[Andrew McCreight [:mccr8]]

Currently ranked #149 on Firefox 29.

Comment 39

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.