842936 - crash in XPCNativeScriptableSharedMap::Entry::Match on devices with amlogic hw running ICS 4.0.4

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Scoobidiver (away)]

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

Comment 1

[Benjamin Smedberg]

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

Comment 2

[Bobby Holley (:bholley)]

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

Comment 3

[Scoobidiver (away)]

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

Comment 4

[Lukas Blakk [:lsblakk] use ?needinfo]

I don't see this in Fennec topcrashers, re-nom if I'm missing something here but otherwise this is not a tracking candidate.

Comment 5

[Scoobidiver (away)]

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

Comment 6

[Lukas Blakk [:lsblakk] use ?needinfo]

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?

Comment 7

[Aaron Train [:aaronmt]]

> 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

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

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.

Comment 9

[Aaron Train [:aaronmt]]

Submitted a request for this one http://www.prestigio.com/products/Tablet_PC/MultiPad/MultiPad_8.0_PRO_DUO #1 in comment #3

Comment 10

[Mark Finkle (:mfinkle) (use needinfo?)]

:jorendroff - any ideas?

Comment 11

[bhavana bajaj [:bajaj]]

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

Comment 12

[Andrew McCreight [:mccr8]]

The last round of weird XPC map failures on Android turned out to be memory corruption by some kind of graphics patch.

Comment 13

[Jason Orendorff [:jorendorff]]

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

Comment 14

[Bobby Holley (:bholley)]

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

Comment 15

[Scoobidiver (away)]

It's #455 crasher in 20.0.

Comment 16

[bhavana bajaj [:bajaj]]

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 .

Comment 17

[Jason Smith [:jsmith]]

not a blocker for 1.3 for the same reasons why this isn't being tracked for fennec or desktop

Comment 18

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