Closed Bug 881431 Opened 12 years ago Closed 12 years ago

[Buri] Crash Reporting UI and push to Socorro is turned off

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

ARM
Gonk (Firefox OS)
defect
Not set
blocker

Tracking

(blocking-b2g:tef+, firefox25 unaffected, b2g18 wontfix, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed, b2g-v1.1hd unaffected)

RESOLVED FIXED
blocking-b2g tef+
Tracking Status
firefox25 --- unaffected
b2g18 --- wontfix
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- fixed
b2g-v1.1hd --- unaffected

People

(Reporter: nhirata, Unassigned)

References

Details

1. adb shell 2. adb kill -11 <b2g process> Expected: reboot of the phone, crash report ui Actual: reboot of phone no crash report ui Note: 1. Doing this should show a pending folder at the very least and it does not show: adb shell cd /data/b2g/mozilla/Crash\ Reports ls
blocking-b2g: --- → tef?
Is this reproducing on Ikura as well?
Naoki, can you please add the build information you tested here ?
Flags: needinfo?(nhirata.bugzilla)
Ikura hasn't been tested because I don't have an Ikura device. Inari wasn't tested because I haven't found an inari build I can test on. I used TEF_powerkey build "06/05 root" build was an engineer build. Currently I have the device flashed to a 6/6 build, which doesn't allow me to reflash it regardless of the volume up+down as it cannot be detected by the computer.
Flags: needinfo?(nhirata.bugzilla)
(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #3) > Ikura hasn't been tested because I don't have an Ikura device. Inari wasn't > tested because I haven't found an inari build I can test on. I believe :tchung tried flashing the Ikura with the latest prod partner build, but since the build did not have root access he was unable to crash the device or perform any other crash related testing. > > I used TEF_powerkey build > "06/05 root" build was an engineer build. > > Currently I have the device flashed to a 6/6 build, which doesn't allow me > to reflash it regardless of the volume up+down as it cannot be detected by > the computer.
i talked to naoki, i'll try testing the crash reporting on the partner builds for both Buri and Ikura. Even though we dont have root access, we still need to investigate why the crash does not launch the Crash Submitting UI on Buri.
(In reply to Tony Chung [:tchung] from comment #5) > i talked to naoki, i'll try testing the crash reporting on the partner > builds for both Buri and Ikura. Even though we dont have root access, we > still need to investigate why the crash does not launch the Crash Submitting > UI on Buri. Okay i really am stuck like Naoki mentioned. Unless i have a way to reliably force a crash, we really need root access to get the build and analyze the crash stacks. Ikura with 5/28 LATAM build: -------------------- - Settings > Improve Firefox OS > Crash Reports > Ask me when a crash ... = checked $ adb shell kill -11 446 /system/bin/sh: kill: 446: Operation not permitted Buri with 6/6 LATAM build ----------------------- Settings > Improve Firefox OS > Crash Reports > Ask me when a crash ... = checked $ adb shell kill -11 446 /system/bin/sh: kill: 446: Operation not permitted So unless I can get into the /data/b2g/mozilla/Crash Reports directory, i can't verify if crash reports are even being sent or not. It worries me that this bug shows that Buri phones dont even show the Crash UI, even though the setting is to "ask me" by default. i havent been able to force crash the Ikura device yet. Any other tips?
(In reply to Tony Chung [:tchung] from comment #6) > (In reply to Tony Chung [:tchung] from comment #5) > > i talked to naoki, i'll try testing the crash reporting on the partner > > builds for both Buri and Ikura. Even though we dont have root access, we > > still need to investigate why the crash does not launch the Crash Submitting > > UI on Buri. > > Okay i really am stuck like Naoki mentioned. Unless i have a way to > reliably force a crash, we really need root access to get the build and > analyze the crash stacks. > > Ikura with 5/28 LATAM build: > -------------------- > - Settings > Improve Firefox OS > Crash Reports > Ask me when a crash ... = > checked > > $ adb shell kill -11 446 > /system/bin/sh: kill: 446: Operation not permitted > > Buri with 6/6 LATAM build > ----------------------- > Settings > Improve Firefox OS > Crash Reports > Ask me when a crash ... = > checked > > $ adb shell kill -11 446 > /system/bin/sh: kill: 446: Operation not permitted > > > So unless I can get into the /data/b2g/mozilla/Crash Reports directory, i > can't verify if crash reports are even being sent or not. It worries me > that this bug shows that Buri phones dont even show the Crash UI, even > though the setting is to "ask me" by default. i havent been able to force > crash the Ikura device yet. Fabrice can help with root access on prod partner builds for Ikura, can you please get in touch with him ? > > Any other tips?
ni? to Amelie
Flags: needinfo?(mei.kong)
Confirmed that Ikura 5/28 is set correctly. i was able to submit a test crash and saw it appear in socorro. crash confirmed: https://crash-stats.mozilla.com/report/index/baa1305f-07dd-4aeb-b2bd-dd0f72130612 That said, Buri is still an issue from the original report.
I'm wondering if this is a POVB with Buri. I have noticed that the Gaia implementation in Buri did change a few things around in Gaia. Although the changes I noticed originally was with the OTA/App updates UI.
To Note : TEF_powerkey build is a May build. I think it was 5/08 or something really old. This is why I was trying to update with a newer production build to test.
(In reply to Tony Chung [:tchung] from comment #9) > crash confirmed: > https://crash-stats.mozilla.com/report/index/baa1305f-07dd-4aeb-b2bd- > dd0f72130612 So we're getting a crash just fine from this build (and device) at least. Unfortunately, as this shows, we don't have any symbols so the report itself is only mildly useful. But I guess that's on a different page anyhow.
(In reply to Robert Kaiser (:kairo@mozilla.com) [away until early June] from comment #12) > (In reply to Tony Chung [:tchung] from comment #9) > > crash confirmed: > > https://crash-stats.mozilla.com/report/index/baa1305f-07dd-4aeb-b2bd- > > dd0f72130612 > > So we're getting a crash just fine from this build (and device) at least. > Unfortunately, as this shows, we don't have any symbols so the report itself > is only mildly useful. But I guess that's on a different page anyhow. Asking partners to provide the symbol now. Thanks for your reminder.
Just to keep on track, this bug is for Buri only. We're still trying to figure out a way to verify the more recent builds. Tchung is currently working on this as I am working on other items at this moment in time.
The Buri build from 20130606 is not building with the crash reporter. ON startup, logcat is reporting: I/GeckoDump( 3080): exception: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsICrashReporter.annotateCrashReport]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: chrome://browser/content/shell.js :: <TOP_LEVEL> :: line 223" data: no] Please build the shipping build with crash reporter enabled.
Severity: normal → blocker
Fabrice, can you please help point out the exact pref/config that may have been disabled here which ideally should have stayed enabled for the crash reported to show up ?
It looks like this build was done with the --disable-crashreporter flag.
blocking-b2g: tef? → tef+
I confirm that this can reproduce in buri :P
TEF-powerkey, TEF-0605, TEF-0611 partner build can reproduce this
After replace the boot img, Buri partner 0606 build can reproduce this issue, too.
I retested the Latam and Polish 6/17 images, and crash reporting UI and submission is working. Poland: https://crash-stats.mozilla.com/report/index/d1b838df-ba7c-4e21-82b4-248e92130618 Latam: https://crash-stats.mozilla.com/report/pending/5025e9c7-f5c2-4a28-8c4c-20f5e2130618) This bus is resolved by partner build.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Flags: needinfo?(mei.kong)
You need to log in before you can comment on or make changes to this bug.