Closed Bug 1525290 Opened Last year Closed 4 months ago

Crash in android.os.RemoteException: at


(Firefox for Android :: General, defect, P1, critical)

Firefox 66



Firefox 71
Tracking Status
firefox-esr68 70+ verified
firefox65 - wontfix
firefox66 --- wontfix
firefox67 --- wontfix
firefox68 - wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- verified


(Reporter: marcia, Assigned: andrei.a.lazar)


(4 keywords)

Crash Data


(2 files)

This bug is for crash report bp-5966ad60-a80c-4c46-8ee0-98d8e0190204.

This is currently #25 overall in Fennec 65 release, but has been in other versions as well: Top crashing devices is Huawei LYA-L29. All crashing devices are running API 28


  • I was being served the desktop website instead of mobile for no matter what I did, so I tried clearing the cache and some other stuff, which is when Firefox crashed.
  • Problems with freezing began previous day when I gave home depot permission to access my location.
  • blank screen on launch
Java stack trace:

	at android.os.Binder.execTransact(

Kevin - Do we have one of these devices (Huawei LYA-L29) that we can try out in our mobile service?

Flags: needinfo?(kbrosnan)

Remote Test Kit has a Mate 20 Pro LYA-L09 which I rented for 20 min. Watched some Youtube, fullscreened a few times, browsed several sites. Did not encounter a crash. I did not see a specific area to test from the comments or the reported URL.

Flags: needinfo?(kbrosnan)

No specific STR, and may be confined to certain devices as discussed during triage. Marking this as a P2. Current volume on 65 is 1320 crashes.

Priority: -- → P2

android.os.RemoteException is actually just a base class for other Binder related exceptions.

RemoteException is thrown if the process hosting the remote object is no longer available, which usually means the process crashed. By looking at the stacktrace - the Binder.execTransact method catches RemoteExceptions and RuntimeExceptions and passes a select few back to the client.

Parcel.writeException is used by the Binder class to marshal the exception into a Parcel and transfer it back to the client, where it will be rethrown as part of Parcel.readException. This makes me believe that this bug and bug 1517485 are related.

This seems pretty difficult to investigate without STRs and to be completely honest I don't know how to proceed further with this. Android does not tunnel exceptions between processes, they are thrown but not directly and we end up with these stacktraces being reported.

@Jan do you have any ideas about these issues ?

Flags: needinfo?(jh+bugzilla)

Unfortunately not, I'm not at all familiar with that area.

Flags: needinfo?(jh+bugzilla)

NI on NAlexander as per our talk on slack.

Flags: needinfo?(nalexander)

(In reply to Ioana Chiorean from comment #6)

NI on NAlexander as per our talk on slack.

Sadly, I don't have anything to contribute here. This is a pretty generic "something happened" with multiple processes/services. It would take me a few days of effort to dig more deeply: into the crash reports, into the Android source, etc.

Flags: needinfo?(nalexander)

Bulk change for all regression bugs with status-firefox67 as 'fix-optional' to be marked 'affected' for status-firefox68.

This is #9 overall in the current 66.0.2 release. Many of the comments continue to mention restarting and crashing when starting Firefox.

(In reply to Marcia Knous [:marcia - needinfo? me] from comment #9)

This is #9 overall in the current 66.0.2 release. Many of the comments continue to mention restarting and crashing when starting Firefox.

The good news is this hasn't been seen in the 67 betas yet.

Crash volume is increasing as we move through the 68 beta cycle - 23 crashes in the last beta.

This is currently #8 overall in release, although volume is not very high.

This moved up into the #5 slot after we unthrottled. Comments are not useful. Wide spectrum of devices affected. APIs are mostly 28 with one crash in API 29.

The top 2 affected graphics adaptors are:


Some URLs:

Currently #3 overall. 100 % correlation to API 28 - (100.0% in signature vs 21.70% overall) android_version = 28 (REL). A few of the comments mention crashing when uploading a video to Facebook. The top 6 devices that are crashing are all HUAWEI. Samsung Galaxy S8 is up in the top 10. Since we are in ESR mode and I am pretty sure we have a Galaxy, should we try to reproduce again?

Flags: needinfo?(sorina.florean)

Hello, I tried to reproduce the crash using the information from comment 13, 14 but I wasn't able.
The scenarios used to reproduce:

  • Upload videos on Facebook, Twitter and Youtube;
  • Change the pages while the video is uploading on Facebook, Twitter, Youtube;
  • Closing and reopening the app while the video is uploading;
  • Put the app in the background for a time and reopening;


  • Samsung Galaxy S8 (Android 9);
  • Huawei P9 Lite (Android 6);


  • Beta-ESR 68.1b3;
  • RC 68.0;
Flags: needinfo?(sorina.florean)

[Tracking Requested - why for this release]:

Crash volume in 68 release is quite high - 19833 crashes so far and continuing into 68.0.2. All the devices are running API 28 as noted before, and huawei devices are at the top of the list of crashing devices. Ideas as to what else we can do here would be be great.

Comments continue to be focused around uploading items, both audio and video.

  • Tried to add a 4GB file to
  • I was Posting My Vid on youtube then firefox just crashed
  • mobile Twitter killed it
  • Posting a video on mobile facebook
  • Tried to upload a large file to Firefox send on Android and just froze

Top crashing devices:

  • Huawei Mate 20 Pro
  • Huawei P20 Pro
  • Huawei P30 Pro
  • Huawei Mate 10 Pro

In terms of phones our QA may have, Pixel 3, Pixel 2, Pixel 2 XL are further down in the list, but are affected.

[Tracking Requested - why for this release]: moving tracking flag for this fennec crash to esr68

Hello Stefan - Can you try to repro again given what I added in Comment 16? Maybe this time try with one of the Pixel devices as well, since they are in the list of crashing devices.

Flags: needinfo?(stefan.deiac)
Attached file crash.txt

I tried to reproduce the crash using the updates from comment 16 on the latest version of FF 68.0.2 and I can confirm that the app it crashes only for a scenario presented.
The app crash but without any crashreport by trying to upload a file un >1G). It seems that you need to wait for a while to reproduce the crash.


  • Google Pixel 3 (Android 9);
  • Google Pixel (Android Q).

Steps to reproduce:

  1. Go to;
  2. Tap on 'Browse' from the 'Start sharing' section;
  3. Choose a file to upload(>= 1G);

Expected result:
The file is uploaded with success;

Actual result:
After a while, the app crash;


  • I attached a pushlog of the crash, hope this helps.
Flags: needinfo?(stefan.deiac)

Making this a P1 based on volume (almost 26K) and the fact we can now reproduce the crash. Petru or Andrei - are you able to take a look now that we can reproduce this issue?

Flags: needinfo?(petru.lingurar)
Flags: needinfo?(andrei.a.lazar)
Keywords: reproducible
Priority: P2 → P1
Assignee: nobody → andrei.a.lazar
Flags: needinfo?(andrei.a.lazar)
Flags: needinfo?(petru.lingurar)
Keywords: stalled

Currently the #3 overall top crash on Fennec release.

Now writing in FileOutputStream on a background thread instead of the main thread.

Keywords: checkin-needed

Pushed by
Crash in android.os.RemoteException: at r=VladBaicu

Keywords: checkin-needed
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
Flags: qe-verify+

Verified as fixed on Nightly 71.0a1 (2019-09-18) with Google Pixel 2 (Android 9).
I will mark this as verified on Firefox 71. Thanks!

Flags: qe-verify+

Comment on attachment 9092705 [details]
Bug 1525290 Crash in android.os.RemoteException: at r=VladBaicu

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This bug is in top 3 crashes for Fennec.
  • User impact if declined: Users won't be able to upload large files (>1GB depending on device).
  • Fix Landed on Version: 70
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This change is small and it simply delegates the work needed (for streaming a file's content from external storage to internal storage) from the main thread to a background thread.
  • String or UUID changes made by this patch:
Attachment #9092705 - Flags: approval-mozilla-esr68?

Comment on attachment 9092705 [details]
Bug 1525290 Crash in android.os.RemoteException: at r=VladBaicu

Approved for Fennec 68.2b4.

Attachment #9092705 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

I tried to reproduce the issue on Beta 68.2b4 on a Samsung Galaxy S8+ (Android 8.0.0) and Pixel 3 XL (Android 9) following the repro steps from comment 19 but was unable to, I will mark this issue as VERIFIED.


68.2b5b4 and 68.2b5 still have crashes as does nightly, so I assume this wasn't totally fixed or there are multiple scenarios going on beyond crashing when uploading files. Andrei - Should I file a new bug or do we want to continue work in this one?

Flags: needinfo?(andrei.a.lazar)

This exception has a wide variety of origins and scenarios, for e.g running services on a dead process, so a new bug would be the best approach. What I'm wondering is if the number of crashes with this signature is reduced.

Flags: needinfo?(andrei.a.lazar)

From the looks of it, there wasn't much of a difference between b3 and b4 in terms of crashes. b3 had 94, and b4 had 79. b5 shows 33 so far.

You need to log in before you can comment on or make changes to this bug.