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+
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 , 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.  http://www.androidxref.com/4.2.2_r1/xref/frameworks/base/core/java/android/app/DownloadManager.java#1169
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+
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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?
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago → 3 years ago
Resolution: --- → 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.