crash in java.lang.IllegalArgumentException: invalid value for param: totalBytes at android.app.DownloadManager.addCompletedDownload(DownloadManager.java)

VERIFIED FIXED in Firefox 35

Status

()

Firefox for Android
General
--
critical
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: aaronmt, Assigned: wesj)

Tracking

({crash})

35 Branch
Firefox 36
All
Android
crash
Points:
---

Firefox Tracking Flags

(firefox35 verified, firefox36 verified, fennec35+)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
This bug was filed from the Socorro interface and is 
report bp-5051449b-30a2-4829-b13e-27ed52140919.
=============================================================

java.lang.IllegalArgumentException:  invalid value for param: totalBytes
	at android.app.DownloadManager.addCompletedDownload(DownloadManager.java:1240)
	at org.mozilla.gecko.GeckoAppShell.scanMedia(GeckoAppShell.java:1812)
	at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method)
	at org.mozilla.gecko.mozglue.GeckoLoader.nativeRun(Native Method)
	at org.mozilla.gecko.GeckoAppShell.runGecko(GeckoAppShell.java:365)
	at org.mozilla.gecko.GeckoThread.run(GeckoThread.java:186)

STR: Saved as PDF
Assignee: nobody → wjohnston
tracking-fennec: ? → 35+
(Assignee)

Comment 2

3 years ago
Comment on attachment 8497066 [details] [diff] [review]
Patch

I'm really not sure how this could happen. Despite not documenting it at all, Android throws if this number is < 0 [1], but file.length() is always >= 0. The only time its not is if you call it with a dir, at which point its undefined. But we're not passing directories in here. If we are, something in the platform is busted. Can't reproduce either, but I imagine maybe we're calling this before the "download"/pdf is actually created, so it returns zero. The Downloads.jsm work will fix that.

Anyway, I don't mind normalizing this number.

[1] http://www.androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/DownloadManager.java#1169
Attachment #8497066 - Attachment description: downloadsize → Patch
Attachment #8497066 - Attachment is patch: true
Attachment #8497066 - Flags: review?(bnicholson)
Comment on attachment 8497066 [details] [diff] [review]
Patch

Review of attachment 8497066 [details] [diff] [review]:
-----------------------------------------------------------------

The download is obviously broken, so I wonder what happens when we try to use addCompletedDownload now. Will we just crash somewhere else? Other than setting the size to 0, I guess our other option would be to avoid the dm.addCompletedDownload call altogether. Hard to say which is best without STR.
Attachment #8497066 - Flags: review?(bnicholson) → review+
https://hg.mozilla.org/mozilla-central/rev/4456d43070b6
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
I am still able to reproduce the crash on Firefox for Android 35.0a1 (2014-10-08) using Samsung Galaxy Tab (Android 4.0.4) : https://crash-stats.mozilla.com/report/index/46f8ef44-d961-4831-87d0-8b7e22141006
Wes - You should have looked at more versions of Android. Newer releases use | if (length < 0) | but older versions use | if (length <= 0) |, so you need to change this patch slightly.

http://androidxref.com/4.0.4/xref/frameworks/base/core/java/android/app/DownloadManager.java#1130
(Reporter)

Updated

3 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 8

3 years ago
Created attachment 8502771 [details] [diff] [review]
Patch v2

Lets just force these to length one in that case then.
Attachment #8502771 - Flags: review?(bnicholson)
Attachment #8502771 - Flags: review?(bnicholson) → review+
Comment on attachment 8502771 [details] [diff] [review]
Patch v2

Approval Request Comment
[Feature/regressing bug #]: bug 816318
[User impact if declined]: Crashes
[Describe test coverage new/current, TBPL]: Crash happens intermittently on TBPL
[Risks and why]: Low/None
[String/UUID change made/needed]: None
Attachment #8502771 - Flags: approval-mozilla-aurora?
Duplicate of this bug: 1070956
Comment hidden (Treeherder Robot)
https://hg.mozilla.org/mozilla-central/rev/cfb35f362bb9
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
status-firefox36: --- → fixed
Attachment #8502771 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
This was fixed on Aurora35 by the uplift of bug 1070086 patch 1.
status-firefox35: affected → fixed
Target Milestone: Firefox 35 → Firefox 36
Verified as fixed in
Builds:
Firefox for Android 36.0a1 (2014-10-24)
Firefox for Android 35.0a2 (2014-10-24)
Device: Asus Transformer TF101 Android 4.0.3
Status: RESOLVED → VERIFIED
status-firefox35: fixed → verified
status-firefox36: fixed → verified
I'm still seeing a significant volume of crashes with this signature, currently our #4 topcrash with 5.31%. However looking at the build IDs from the reports they are all on October 22nd builds or earlier. Given this is a startup crash we might have some Aurora users who are unable to update. I'm not sure what can be done about that, I'm merely stating it as a matter of fact.
In supplement to comment 16, it looks like there are 10 users affected. Based on ADIs this is reflective of 0.7% of our Aurora users.
You need to log in before you can comment on or make changes to this bug.