870782 - Nightly-only crash in nsXPCWrappedJS::CallMethod

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

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)

Comment 1

[Ed Morley [:emorley]]

Seeing this as a perma-crash on Firefox for Android nightlies - mozilla-central closed as a result:
https://tbpl.mozilla.org/?rev=08be63954b6b&jobname=Android

Example logs:
https://tbpl.mozilla.org/php/getParsedLog.php?id=22818518&tree=Mozilla-Central
https://tbpl.mozilla.org/php/getParsedLog.php?id=22818146&tree=Mozilla-Central
https://tbpl.mozilla.org/php/getParsedLog.php?id=22818534&tree=Mozilla-Central

Is affecting Android 2.2 (ARM + x86) and Android 4.0 (ARM).

Comment 2

[Ed Morley [:emorley]]

Initial regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea059733677c&tochange=08be63954b6b

Comment 3

[Ed Morley [:emorley]]

Firefox for Android Nightly update snippets have been pulled as of 8 mins ago.

Comment 4

[(PTO May 7-12) Ryan VanderMeulen [:RyanVM]]

--enable-profiling bites us (again)?

Comment 5

[Josh Matthews [:jdm]]

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.

Comment 6

[Josh Matthews [:jdm]]

http://mxr.mozilla.org/mozilla-central/source/mobile/android/components/DirectoryProvider.js

Comment 7

[Josh Matthews [:jdm]]

nsFetchTelemetryData runs on a non-main thread and uses NS_GetSpecialDirectory which activates the directory service providers, causing badness.

Comment 8

[Josh Matthews [:jdm]]

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.

Comment 9

[Nathan Froyd [:froydnj]]

Attachment: call NS_GetSpecialDirectory on the main thread rather than off-mainthread in telemetry

I think this should fixup the issue.

Comment 10

[Nathan Froyd [:froydnj]]

Attachment: call NS_GetSpecialDirectory on the main thread rather than off-mainthread in telemetry

Better patch.

Comment 11

[Vladan Djeric (:vladan)]

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)

Comment 12

[Kevin Brosnan [Ex-Mozilla]]

This looks to affect Fx 23. QA would like this fixed on Aurora before turning on updates for Android.

Comment 13

[Scoobidiver (away)]

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.

Comment 14

[(PTO May 7-12) Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/85562dbf54ad