1525290 - Crash in android.os.RemoteException: at com.android.server.job.JobServiceContext.assertCallerLocked(JobServiceContext.java)

Status: VERIFIED FIXED

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

Description

[Marcia Knous [:marcia]]

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: https://bit.ly/2DdjJ9f. Top crashing devices is Huawei LYA-L29. All crashing devices are running API 28

Comments:

• I was being served the desktop website instead of mobile for Microcenter.com 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:

android.os.RemoteException
	at com.android.server.job.JobServiceContext.assertCallerLocked(JobServiceContext.java:489)
	at com.android.server.job.JobServiceContext.doCompleteWork(JobServiceContext.java:390)
	at com.android.server.job.JobServiceContext$JobCallback.completeWork(JobServiceContext.java:165)
	at android.app.job.IJobCallback$Stub.onTransact(IJobCallback.java:101)
	at android.os.Binder.execTransact(Binder.java:739)

Comment 1

[Marcia Knous [:marcia]]

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

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 3

[Marcia Knous [:marcia]]

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.

Comment 4

[Vlad Baicu]

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 ?

Comment 5

[Jan Henning [:JanH]]

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

Comment 6

[Ioana Chiorean]

NI on NAlexander as per our talk on slack.

Comment 7

[Nick Alexander :nalexander [he/him]]

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

Comment 8

[Neha Kochar [:neha]]

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

Comment 9

[Marcia Knous [:marcia]]

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

Comment 10

[Marcia Knous [:marcia]]

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

Comment 11

[Marcia Knous [:marcia]]

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

Comment 12

[Marcia Knous [:marcia]]

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

Comment 13

[Marcia Knous [:marcia]]

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:

*Mali-G76
*Mali-G72

Some URLs:

• https://mobile.twitter.com/home
• https://www.flightradar24.com/data/flights/ba3290
• https://www.lemonde.fr
• https://www.youtube.com/upload
• https://www.apple.com/cn-k12/shop/buy-mac/macbook-pro/13-%E8%8B%B1%E5%AF%B8
• https://thecrashcourse.com/

Comment 14

[Marcia Knous [:marcia]]

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?

Comment 15

[Stefan Deiac]

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;

Devices:

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

Build:

• Beta-ESR 68.1b3;
• RC 68.0;

Comment 16

[Marcia Knous [:marcia]]

[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 instant.io
• 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.

Comment 17

[Julien Cristau [:jcristau] (back on 2026-01-06)]

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

Comment 18

[Marcia Knous [:marcia]]

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.

Comment 19

[Stefan Deiac]

Attachment: crash.txt

Hello
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 instant.io(file >1G). It seems that you need to wait for a while to reproduce the crash.

Devices:

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

Steps to reproduce:

1. Go to instant.io;
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;

Notes:

• I attached a pushlog of the crash, hope this helps.

Comment 20

[Marcia Knous [:marcia]]

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?

Comment 21

[Marcia Knous [:marcia]]

Currently the #3 overall top crash on Fennec release.

Comment 22

[Andrei Lazar]

Attachment: Bug 1525290 Crash in android.os.RemoteException: at com.android.server.job.JobServiceContext.assertCallerLocked(JobServiceContext.java) r=VladBaicu

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

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fbfcb1c069c5
Crash in android.os.RemoteException: at com.android.server.job.JobServiceContext.assertCallerLocked(JobServiceContext.java) r=VladBaicu

Comment 24

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/fbfcb1c069c5

Comment 25

[Andrei Lazar]

Try build with my patch applied over the current ESR tip - https://treeherder.mozilla.org/#/jobs?repo=try&revision=dc0af19a10bab4005646604775c754135bf4909b

Comment 26

[Eliza Balazs]

Hi!
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!

Comment 27

[Andrei Lazar]

Comment on attachment 9092705 [details]
Bug 1525290 Crash in android.os.RemoteException: at com.android.server.job.JobServiceContext.assertCallerLocked(JobServiceContext.java) 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:

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9092705 [details]
Bug 1525290 Crash in android.os.RemoteException: at com.android.server.job.JobServiceContext.assertCallerLocked(JobServiceContext.java) r=VladBaicu

Approved for Fennec 68.2b4.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr68/rev/9d6b76c3c350

Comment 30

[Laurentiu Apahidean]

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.

Comment 31

[Marcia Knous [:marcia]]

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?

Comment 32

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

Comment 33

[Marcia Knous [:marcia]]

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.

Comment 34

[Chris Peterson [:cpeterson]]

Removing regressionwindow-wanted keyword because this bug has been resolved.

Comment 35

[Chris Peterson [:cpeterson]]

Removing regressionwindow-wanted keyword because this bug has been resolved.

Comment 36

[Chris Peterson [:cpeterson]]

Removing regressionwindow-wanted keyword because this bug has been resolved.