[FHR] Crashing gmp using media.gmp.plugin.crash pref does not store data in FHR

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
4 years ago
a month ago

People

(Reporter: bogdan_maris, Unassigned)

Tracking

(Blocks: 1 bug)

34 Branch
x86
Linux
Dependency tree / graph
Bug Flags:
firefox-backlog -

Firefox Tracking Flags

(Not tracked)

Details

Reproduced on latest Nightly 34.0a1 (buildID: 20140813030201).

STR:
1. Open Nightly with new profile.
2. Wait for OpenH264 plugin to install.
3. Visit http://mozilla.github.io/webrtc-landing/pc_test.html and start a h.264 video call
4. Set pref 'media.gmp.plugin.crash' as 'false' (you need to create it)
5. While the call is on, change the pref value to 'true'
6. Submit a crash report.
7. Visit about:healthreport
8. Search for crash data:
eg: "org.mozilla.crashes.crashes": {
          "_v": 5,
          "gmplugin-crash": 1,
          "main-crash": 1,
          "main-crash-submission-succeeded": 1

Expected result: First crash records data in FHR.

Actual result: First crash does not record data in FHR.

Notes:
1. This issue does not happen every time, sometime I have data but not the same structure as the example from above.
2. Possibly the cause of this bug is bug 1049501.
3. I`ve seen this only on Linux platform. (testing on Ubuntu 14.04 32bit)
Depends on: 1009765
Blocks: 948160
Whiteboard: [openh264-uplift]

Updated

4 years ago
Flags: firefox-backlog+

Comment 1

4 years ago
Does the crash still not show up even after you wait a few minutes and restart Firefox? There is an inherent delay between recording crashes in the crash manager and having them show up in FHR.

Updated

4 years ago
Flags: needinfo?(bogdan.maris)
After waiting for about 10 minutes, the crash still does not appear in FHR, but after a restart the crash does appear in FHR.

"org.mozilla.crashes.crashes": {
     "_v": 5,
     "gmplugin-crash": 1,
     "main-crash-submission-succeeded": 1
Flags: needinfo?(bogdan.maris)

Comment 3

4 years ago
It sounds like this is working as expected, then. gps can you confirm that a delay between adding a crash to the CrashManager and having it show up in the FHR payload is expected? And is there a way for QA to force a refresh using the browser console, for faster testing?
Flags: needinfo?(gps)

Comment 4

4 years ago
You can force an FHR collection by going to about:healthreport.

The crashes FHR provider does not ensure the CrashManager is up-to-date before grabbing data. That's arguably an oversight and is a one-line fix (plus tests) to correct, if desired.
Flags: needinfo?(gps)

Comment 5

4 years ago
I don't understand what "CrashManager is up-to-date" means in this context. GMP crashes don't write event files, they send the crash directly to the crash manager. So the CrashManager should always be up to date.

Bogdan, you are getting the data delay specifically by loading about:healthreport, right?
Flags: needinfo?(bogdan.maris)
I may have made a mistake in the STR from comment 0. I have about:healthreport opened in a tab when I crash the plugin. After submitting the crash I reload the tab with FHR and the data is not there, no data is written even if I close and reopen FHR in new tab/new window. Not having about:healthreport opened in a tab and opening FHR after the crash does store data. Sorry for the confusion.
Flags: needinfo?(bogdan.maris)

Comment 7

4 years ago
ok, I don't think there's a bug we need to fix here.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX

Updated

4 years ago
Flags: firefox-backlog+ → firefox-backlog-

Updated

4 years ago
Whiteboard: [openh264-uplift]

Updated

a month ago
Product: Firefox Health Report → Firefox Health Report Graveyard
You need to log in before you can comment on or make changes to this bug.