Closed Bug 738168 Opened 9 years ago Closed 8 years ago

Moving Fennec to the SDCard will prevent crash reports from being copied to the profile, ie no crash report will be reported to Socorro

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set
major

Tracking

()

VERIFIED WORKSFORME
Tracking Status
blocking-fennec1.0 --- soft

People

(Reporter: aryx, Assigned: gcp)

References

Details

Attachments

(2 files)

Fennec native trunk 2012-03-21, Android 4.0.3 (stock), Google Nexus S

I got some crashes yesterday and today and Breakpad (Mozilla's crash reporter) popped up and I submitted the crash reports. They are also listed in 
/data/data/org.mozilla.fennec/files/mozilla/Crash Reports/ in either the subfolders submitted and pending.

But the about:crashes page doesn't list them, the last crash report there is from 2012-01-10.

Bug 731903 is about Java crashes caught by Android, so not a duplicate.
Shouldn't matter if Java crashes or not, as long as our crash reporter catches them (but not if Android itself catches them), they should show up in about:crashes. Naoki, do you know of any breakage there?
Aryx, would it be possible for you to attach your crash report with this bug?
(Is your device rooted?)

The other question is can you do a refresh on the about:crashes and is it still not showing the link?
The device is rooted, you find the Crash Reports folder attached.

Choosing the 'Reload' option from the menu doesn't change the list, but for your information, I remember to have seen Fennec caching (web) pages which it shouldn't (after session restore on launch) last week.
Thanks for the Crash Report.  looking at the info it looks like it's stuck in pending... cc'ing Ted.
I just crashed today and crash reports are sended just fine here on the Galaxy Nexus, Android 4.0.2.
You'd probably have to check logcat while submitting to see if anything interesting shows up. I don't think the Android crash reporter writes a log with submit errors, we should probably fix that.
I don't see any failures in that logcat, unless it happened in the part of the log after you trimmed it:
I/GeckoCrashReporter(23268): sendReport: /data/data/org.mozilla.fennec/files/mozilla/Crash Reports/pending/78dcc5ed-db5c-01ad-57da0ce6-54a271a6.dmp
I/GeckoCrashReporter(23268): server url: https://crash-reports.mozilla.com/submit?id={aa3c5121-dab2-40e2-81ca-7ea25febc110}&version=14.0a1&buildid=20120323031214
The mini dump isn't being found... I'm guessing it wasn't written at all?

I/GeckoCrashReporter(23268): moving /mnt/sdcard/Android/data/org.mozilla.fennec/files/mozilla/ohhxvfs8.default/minidumps/78dcc5ed-db5c-01ad-57da0ce6-54a271a6.dmp to /data/data/org.mozilla.fennec/files/mozilla/Crash Reports/pending/78dcc5ed-db5c-01ad-57da0ce6-54a271a6.dmp
I/GeckoCrashReporter(23268): couldn't rename minidump file
E/GeckoCrashReporter(23268): exception while copying minidump file: 
E/GeckoCrashReporter(23268): java.io.FileNotFoundException: /mnt/sdcard/Android/data/org.mozilla.fennec/files/mozilla/ohhxvfs8.default/minidumps/78dcc5ed-db5c-01ad-57da0ce6-54a271a6.dmp: open failed: ENOENT (No such file or directory)
Whiteboard: qawanted
Arch, can you try again?  Also have you moved fennec to your SDcard?
I don't think I've ever seen a situation like that where we launched the crash reporter but completely failed to write the dump. Usually when we fail we leave a zero-byte file behind.
I'm still experiencing the issue. I have moved Fennec to the SDcard while it was still on XUL (now I see it's still on the SDcard, was sure the phone showed Fennec being in its default store when I reported the bug).

In /data/data/org.mozilla.fennec/files/mozilla/Crash Reports/pending/ there are crash reports with dates from late March and early April. Is it coincidence that the crash reports start only with numbers 0, 2 and 4-6?

about:crashes is showing the crash reports found in /mnt/sdcard/Android/data/org.mozilla.fennec/files/mozilla/Crash Reports/pending/

So the newer crash reports are saved for some reasons in the internal memory.

/mnt/sdcard/Android/data/org.mozilla.fennec/files/mozilla/ohhxvfs8.default/minidumps/ contains 4 pairs of files, each from a different month (2011-10, 2012-01, 2012-03 and 2012-04).

Tell me if you need the crash reports and/or the minidumps (and please tell me if they can contain private information or where I can look this up).
We used to have the profile move as well to the SDcard when Fennec was on XUL; we had fixed that in a bug.  Native Fennec now stores on the internal memory to protect information that's in the profile.  Is it possible that you had a really old version of XUL fennec and then upgraded to the latest Native Fennec?  If this is the case, I wonder if you're experiencing write permission issues to the profile when you crash?

Have you tried uninstalling / reinstall fennec native since this issue?
Doh.  I was able to replicate with today's nightly XUL and today's nightly Native.

1. install nightly
2. move app to SDcard
3. relaunch app; go to http://people.mozilla.com/~nhirata/html_tp/bug725953.html
4. hit the browse button
5. select a 3rd party file picker like astro
6. hit back twice
7. restart fennec, and go to about:crashes

Expected: crash report
Actual: no crash report

There's no need to have a previous version of XUL fennec, though it reproduces with a XUL fennec upgrade as well.  Thanks Arch. for the report!
blocking-fennec1.0: --- → ?
Whiteboard: qawanted
blocking-fennec1.0: ? → -
blocking-fennec1.0: - → soft
Summary: about:crashes not updated with new crash reports submitted by Crash Reporter/Breakpad (missing from the list) → Moving Fennec to the SDCard will prevent crash reports from being copied to the profile, ie no crash report will be reported to Socorro
Assignee: nobody → gpascutto
Note: shouldn't hardcode /data/data/etc in the Crash Reporter but figure it from Context.getFilesDir()
This isn't reproducible for me in the non-upgrade scenario.

1) Install Native Fennec
2) Move to SDCard
3) Launch Fennec
4) Force a kill with adb shell run-as org.mozilla.fennec_me kill -11 pid
5) See crash reporter pop up, click submit
6) Relaunch Fennec, go to about:crashes, crashes are present, links go to crash logs on the server

Android log looks as expected too:

I/GeckoCrashReporter( 9506): moving /data/data/org.mozilla.fennec_morbo/files/mozilla/872by5k3.default/minidumps/40b823db-8a3d-0410-14c721aa-741f5d37.dmp to /data/data/org.mozilla.fennec_morbo/files/mozilla/Crash Reports/pending/40b823db-8a3d-0410-14c721aa-741f5d37.dmp
I/GeckoCrashReporter( 9506): moving /data/data/org.mozilla.fennec_morbo/files/mozilla/872by5k3.default/minidumps/40b823db-8a3d-0410-14c721aa-741f5d37.extra to /data/data/org.mozilla.fennec_morbo/files/mozilla/Crash Reports/pending/40b823db-8a3d-0410-14c721aa-741f5d37.extra
I/GeckoCrashReporter( 9506): sendReport: /data/data/org.mozilla.fennec_morbo/files/mozilla/Crash Reports/pending/40b823db-8a3d-0410-14c721aa-741f5d37.dmp
I/GeckoCrashReporter( 9506): server url: https://crash-reports.mozilla.com/submit?id={aa3c5121-dab2-40e2-81ca-7ea25febc110}&version=15.0a1&buildid=20120604182743

I'll fiddle with the upgrade scenario now to see if I can make that break.
Not reproducible even in the upgrade scenario.

1) Install XUL Fennec
2) Move to SDCard
3) Update to Native
4) Proceed as in previous comment.

Android log again looks as expected, moves the profile to the new dir:

I/GeckoProfile(22289): New installation or update, checking for old profiles.
D/ProfileMigrator(22289): Moving old profile directories from /mnt/sdcard/Android/data/org.mozilla.fennec_morbo/files/mozilla
...
I/GeckoCrashReporter(22473): moving /data/data/org.mozilla.fennec_morbo/files/mozilla/v59gqub7.default/minidumps/3d2f3f8d-9914-1fa2-353a4341-1e9f1970.dmp to /data/data/org.mozilla.fennec_morbo/files/mozilla/Crash Reports/pending/3d2f3f8d-9914-1fa2-353a4341-1e9f1970.dmp
I/GeckoCrashReporter(22473): moving /data/data/org.mozilla.fennec_morbo/files/mozilla/v59gqub7.default/minidumps/3d2f3f8d-9914-1fa2-353a4341-1e9f1970.extra to /data/data/org.mozilla.fennec_morbo/files/mozilla/Crash Reports/pending/3d2f3f8d-9914-1fa2-353a4341-1e9f1970.extra

Bug 746860 might have fixed this? I'm going to close this as WORKSFORME. Cleaning up the /data/data hardcoding should probably go into a separate bug.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
Verified fixed in Fennec trunk nightly 2012-06-07
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.