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 ?

> Can we get a url list for this crash ? ping

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

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

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

Need a blocking decision for mozilla-1.9.2

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.

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.

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...

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

This still a beta2 blocker, or more betaN?

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.

I have this in recording.

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).

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.

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)

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

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

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.

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

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

(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!

(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.

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

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

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

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

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

Currently ranked #149 on Firefox 29.

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.