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

NEW
Unassigned

Status

()

Core
XPConnect
--
critical
5 years ago
2 years ago

People

(Reporter: Scoobidiver (away), Unassigned)

Tracking

({crash})

19 Branch
ARM
Android
crash
Points:
---

Firefox Tracking Flags

(firefox19 affected, firefox20+ wontfix, firefox21- affected, fennec-)

Details

(Whiteboard: [native-crash][startupcrash], crash signature)

(Reporter)

Description

5 years ago
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

5 years ago
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
Flags: needinfo?(jorendorff)
(Reporter)

Comment 3

5 years ago
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
(Reporter)

Updated

5 years ago
tracking-firefox20: --- → ?
Keywords: topcrash
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: ? → -
(Reporter)

Comment 5

5 years ago
(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
tracking-fennec: --- → ?

Updated

5 years ago
QA Contact: aaron.train
> 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
: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.
Flags: needinfo?(jorendorff)
(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.
(Reporter)

Comment 15

5 years ago
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: ? → -
tracking-fennec: ? → -

Updated

4 years ago
blocking-b2g: --- → 1.3?
not a blocker for 1.3 for the same reasons why this isn't being tracked for fennec or desktop
blocking-b2g: 1.3? → ---

Updated

2 years ago
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.