Nightly-only crash in nsXPCWrappedJS::CallMethod

RESOLVED FIXED in Firefox 24

Status

()

defect
--
critical
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: aaronmt, Unassigned)

Tracking

(4 keywords)

24 Branch
Firefox 24
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox22 unaffected, firefox23+ unaffected, firefox24 fixed)

Details

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

Attachments

(1 attachment, 1 obsolete attachment)

This bug was filed from the Socorro interface and is 
report bp-0becae4f-6337-4ccf-b959-016142130510 .
============================================================= 

I seem to get this crash just idling my device on any site including about:home

--
Nightly (05/10)
LG Nexus 4 (Android 4.2.2)
Whiteboard: [native-crash]
Summary: Crash in nsXPCWrappedJS::CallMethod → Nightly-only crash in nsXPCWrappedJS::CallMethod
Firefox for Android Nightly update snippets have been pulled as of 8 mins ago.
Severity: critical → blocker
--enable-profiling bites us (again)?
This was caused by the off-main-thread XPCWrappedJS changes in bug 770840. The stack shown is confusing, so I can't quite tell what we're actually doing that causes us to use a wrapped object, unless we are implementing some kind of directory provider in JS on Android. If we are, it looks like we shouldn't.
Blocks: 773610
nsFetchTelemetryData runs on a non-main thread and uses NS_GetSpecialDirectory which activates the directory service providers, causing badness.
The easiest fix is probably to modify ReadLateWritesStacks (http://hg.mozilla.org/mozilla-central/annotate/08be63954b6b/toolkit/components/telemetry/Telemetry.cpp#l1717) and nsFetchTelemtryData such that the profile directory path is obtained by the runnable's constructor on the main thread.
Blocks: 770840
tracking-fennec: --- → ?
Comment on attachment 748012 [details] [diff] [review]
call NS_GetSpecialDirectory on the main thread rather than off-mainthread in telemetry

> nsresult
>-GetFailedProfileLockFile(nsIFile* *aFile, nsIFile* aProfileDir = nullptr)
>+GetFailedProfileLockFile(nsIFile* *aFile, nsIFile* aProfileDir)
> {
>-  nsresult rv;
>-  if (aProfileDir) {
>-    rv = aProfileDir->Clone(aFile);
>-  } else {
>-    rv = NS_GetSpecialDirectory(NS_APP_USER_PROFILE_50_DIR, aFile);
>-  }
>+  nsresult rv = aProfileDir->Clone(aFile);
>   NS_ENSURE_SUCCESS(rv, rv);
> 
>   (*aFile)->AppendNative(NS_LITERAL_CSTRING("Telemetry.FailedProfileLocks.txt"));
>   return NS_OK;
> }

NS_ENSURE_ARG_POINTER(aProfileDir)
Attachment #748012 - Flags: review?(vdjeric) → review+
Severity: blocker → critical
This looks to affect Fx 23. QA would like this fixed on Aurora before turning on updates for Android.
It has been fixed by the backout of bug 770840.
It stays open to fix the underlying issue once the patch of bug 770840 lands again.
Version: Trunk → Firefox 24
https://hg.mozilla.org/mozilla-central/rev/85562dbf54ad
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
tracking-fennec: ? → ---
Duplicate of this bug: 871125
You need to log in before you can comment on or make changes to this bug.