It's currently #38 top crasher in the first hours of 19.0. Signature XPCNativeScriptableSharedMap::Entry::Match(JSDHashTable*, JSDHashEntryHdr const*, void const*) More Reports Search UUID bf11096f-1078-490a-8d50-02e152130220 Date Processed 2013-02-20 04:20:29 Uptime 6 Last Crash 1.3 days before submission Install Age 4.5 weeks since version was first installed. Install Time 2013-01-19 23:41:02 Product FennecAndroid Version 19.0 Build ID 20130116072507 Release Channel beta OS Android OS Version 0.0.0 Linux 3.0.8-ge04d3bb #98 SMP PREEMPT Mon Nov 12 20:59:51 CST 2012 armv7l MID/ASBSM767ND/ASBSM767ND:4.0.4/IMM76I/eng.root.20121109.175558:user/release-keys Build Architecture arm Build Architecture Info Crash Reason SIGSEGV Crash Address 0x5e500000 App Notes AdapterDescription: 'ARM -- Mali-400 MP -- OpenGL ES 2.0 -- Model: PMP5770D, Product: PMP5770D, Manufacturer: Prestigio, Hardware: amlogic' EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ Prestigio PMP5770D MID/ASBSM767ND/ASBSM767ND:4.0.4/IMM76I/eng.root.20121109.175558:user/release-keys Processor Notes sp-processor09.phx1.mozilla.com_21140:2008; MDSW emitted too many frames, triggering truncation; exploitablity tool: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID ARM Adapter Device ID Mali-400 MP Device Prestigio PMP5770D Android API Version 15 (REL) Android CPU ABI armeabi-v7a Frame Module Signature Source 0 libc.so libc.so@0xe148 1 dalvik-heap (deleted) dalvik-heap @0x71acf1a 2 libxul.so XPCNativeScriptableSharedMap::Entry::Match js/xpconnect/src/XPCMaps.cpp:549 3 libxul.so JS_DHashTableOperate js/src/jsdhash.cpp:399 4 libxul.so XPCNativeScriptableSharedMap::GetNewOrUsed js/xpconnect/src/XPCMaps.cpp:597 5 libxul.so XPCNativeScriptableInfo::Construct js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1325 6 libxul.so XPCWrappedNative::Init js/xpconnect/src/XPCWrappedNative.cpp:1109 7 libxul.so XPCWrappedNative::GetNewOrUsed js/xpconnect/src/XPCWrappedNative.cpp:632 8 libxul.so XPCConvert::NativeInterface2JSObject js/xpconnect/src/XPCConvert.cpp:922 9 libxul.so NativeInterface2JSObject js/xpconnect/src/nsXPConnect.cpp:1215 10 libxul.so nsXPConnect::WrapNativeToJSVal js/xpconnect/src/nsXPConnect.cpp:1272 11 libxul.so xpc::WrapperFactory::PrepareForWrapping js/xpconnect/wrappers/WrapperFactory.cpp:260 12 libxul.so JSCompartment::wrap js/src/jscompartment.cpp:292 13 libxul.so js::CrossCompartmentWrapper::get js/src/jswrapper.cpp:502 14 libxul.so proxy_GetGeneric js/src/jsproxy.cpp:2377 15 libxul.so js_IteratorMore js/src/jsobjinlines.h:170 16 libxul.so js::Interpret js/src/jsinterp.cpp:978 17 libxul.so js::RunScript js/src/jsinterp.cpp:326 ... More reports at: https://crash-stats.mozilla.com/report/list?signature=XPCNativeScriptableSharedMap%3A%3AEntry%3A%3AMatch%28JSDHashTable*%2C+JSDHashEntryHdr+const*%2C+void+const*%29
bholley, does this look familiar at all? If I were a betting man, I'd say we're probably passing garbage to strcmp here: http://hg.mozilla.org/releases/mozilla-beta/annotate/46305160fb3c/js/xpconnect/src/XPCMaps.cpp#l549
Assignee: nobody → bobbyholley+bmo
(In reply to Benjamin Smedberg [:bsmedberg] from comment #1) > bholley, does this look familiar at all? If I were a betting man, I'd say > we're probably passing garbage to strcmp here: > http://hg.mozilla.org/releases/mozilla-beta/annotate/46305160fb3c/js/ > xpconnect/src/XPCMaps.cpp#l549 That looks like a reasonable guess as to the crash. We construct the JSClasses here, where the class name comes from the call to nsIXPCScriptable::GetClassName. http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCWrappedNativeJSOps.cpp#1242 The only implementation I can see for this is nsDOMClassInfo::GetClassName, which just does NS_strdup(mData->mName); Once this thing is created, it lives in the hashmap, where it undergoes a periodic mark/sweep during GC. If this thing is unmarked, then it gets deleted and removed from the hashmap by JSClassSweeper: http://mxr.mozilla.org/mozilla-central/source/js/xpconnect/src/XPCJSRuntime.cpp#150 So the XPCNativeScriptableShared owns the JSClass name, and should die at the same time it's removed from the hashmap. So I don't see anything obviously wrong here. I'm a bit fuzzy on the proper semantics of JSDHash, so I might be missing a hazard with respect to the transfer of ownership in XPCNativeScriptableSharedMap::GetNewOrUsed. Jorendorff, can you audit the implementation of XPCNativeScriptableSharedMap::GetNewOrUsed and make sure it looks generally sane with respect to hashtable usage? Should be very quick. Other than that, I'm out of ideas.
Assignee: bobbyholley+bmo → nobody
It has a rising tendency. Indeed, it's now #14 top crasher in 19.0 and #13 in 19.0.2. It happens only on Android 4.0.4 with Mali 400 MP and amlogic hw. Here are affected devices (more than 4 crashes): YIFANG PMP5580C 46 (see http://pdadb.net/index.php?m=specs&id=4284&view=1&c=prestigio_multipad_8.0_pmp5580c_pro_duo) Prestigio PMP5770D 24 YIFANG GASEM805MC 21 MID Novo7Flame 13 YIFANG PTM712MCFC1 12 Positivo YPY_TQ7 10 YIFANG BOULM805ND 9 YIFANG NXM805ND_EN 9 Gemei MID gemei G6 7 YIFANG M-MP860S2 6 YIFANG WALMM752MC 6 MID Novo7Fire 6 YIFANG POM727MC 5 YIFANG PTM723MR 5 YIFANG PTM805MC 5 MID ELF-II 5 YIFANG GASEM712MC 4 YIFANG STM805ND 4 YIFANG CT710 4 YIFANG PMP5770D 4 YIFANG CT710FR 4 Positivo YPY_AB10D 4 Positivo YPY_10STB 4 Positivo YPY_07STB 4 MID Matrix III 4
status-firefox20: --- → affected
status-firefox21: --- → affected
Summary: crash in XPCNativeScriptableSharedMap::Entry::Match → crash in XPCNativeScriptableSharedMap::Entry::Match on devices with amlogic hw running ICS 4.0.4
I don't see this in Fennec topcrashers, re-nom if I'm missing something here but otherwise this is not a tracking candidate.
tracking-firefox20: ? → -
(In reply to Lukas Blakk [:lsblakk] from comment #4) > I don't see this in Fennec topcrashers, re-nom if I'm missing something here > but otherwise this is not a tracking candidate. See https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/19.0.2 The breakdown of those devices is different between the Release and Beta populations.
tracking-firefox20: - → ?
We'll track this then since we know it will likely pop up in more volume after we release - can QA work with that device list to try and find some STR?
tracking-firefox20: ? → +
tracking-firefox21: --- → +
Keywords: qawanted, steps-wanted
> Can QA work with that device list to try and find some STR? Not at the moment, no. These are all international devices. The two high-volume devices seem to be manufactured and sold in the Czech Republic. > Gemei MID gemei G6 http://product.pconline.com.cn/tabletmid/gemei/520453.html
Wontfixing for 20 given the lack of device but Aaron is going to own putting in a ServiceNow request to get a device located for testing in the FF21 timeframe.
status-firefox20: affected → wontfix
Submitted a request for this one http://www.prestigio.com/products/Tablet_PC/MultiPad/MultiPad_8.0_PRO_DUO #1 in comment #3
:jorendroff - any ideas?
tracking-fennec: ? → 21+
(In reply to Mark Finkle (:mfinkle) from comment #10) > :jorendroff - any ideas? reached out :jorendroff on irc a few mins back, he should be helping with the needinfo on this.
The last round of weird XPC map failures on Android turned out to be memory corruption by some kind of graphics patch.
(In reply to Bobby Holley (:bholley) from comment #2) > Jorendorff, can you audit the implementation of > XPCNativeScriptableSharedMap::GetNewOrUsed and make sure it looks generally > sane with respect to hashtable usage? Should be very quick. Well... Entry* entry = (Entry*) JS_DHashTableOperate(mTable, &key, JS_DHASH_ADD); ... entry->key = shared = new XPCNativeScriptableShared(flags, key.TransferNameOwnership(), interfacesBitmap); if (!shared) return false; That last return false, if we get there, that might cause this. It would leave a live entry in the table with entry->key == NULL. But we crash hard if `new` fails, right? So we can't get there.
(In reply to Jason Orendorff [:jorendorff] from comment #13) > But we crash hard if `new` fails, right? So we can't get there. Yeah, exactly. So I'm stumped.
It's #455 crasher in 20.0.
tracking-fennec: 21+ → ?
tracking-firefox21: + → ?
Keywords: qawanted, steps-wanted, topcrash
Untracking as this is no longer a top-crasher.Checked crash-stats for 21.0b1,and this is not in the top-crash list so does not not qualify for tracking. Please renominate if I am missing something here and this needs to be tracked .
tracking-firefox21: ? → -
not a blocker for 1.3 for the same reasons why this isn't being tracked for fennec or desktop
blocking-b2g: 1.3? → ---
Crash Signature: [@ XPCNativeScriptableSharedMap::Entry::Match(JSDHashTable*, JSDHashEntryHdr const*, void const*)] → [@ XPCNativeScriptableSharedMap::Entry::Match(JSDHashTable*, JSDHashEntryHdr const*, void const*)] [@ XPCNativeScriptableSharedMap::Entry::Match]
You need to log in before you can comment on or make changes to this bug.