Not getting OOPP crash reports for Flash Version: 11.4.402.265

RESOLVED FIXED in Firefox 18

Status

()

Toolkit
Crash Reporting
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: marcia, Assigned: ted)

Tracking

unspecified
mozilla18
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(firefox16-, firefox17-, firefox18+ fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Created attachment 654382 [details]
Screenshot using 11.4.402.265 on Mac 10.8

When testing Version: 11.4.402.265 on Mac, I do not get a Flash crash report for a crash, but I do get one when testing with 11.3.300.271.

STR:
1. Load http://flonga.com/play/paws.htm
2. Crash.
3. Note attached screenshot which is what I get using 11.4.402.265 on 10.8.
(Reporter)

Comment 1

6 years ago
Testing on a 10.6 machine with 11.3.300.271, I am able to submit a crash report and it crashes in [@ FlashPlayer-10.6@0x2c6d36].

Comment 2

6 years ago
This is not a Socorro (i.e. server-side) bug but you say the reports are not even sent, so it's on the client side. I hope Benjamin or Ted can help there.
Component: General → Breakpad Integration
Product: Socorro → Toolkit
(Assignee)

Comment 3

6 years ago
Last I checked, OOP crash reporting was totally broken on 10.7+. I just haven't had time to fix it because we're way out of sync with upstream Breakpad, and I don't know exactly what fixed it.

Updated

6 years ago
tracking-firefox16: --- → ?

Comment 4

6 years ago
Are we running mochitests on 10.7/10.8? We do test basic OOPP crash reporting in mochitests.
(Assignee)

Comment 5

6 years ago
We have tests on 10.7, and those tests are failing.

Comment 6

6 years ago
(In reply to Ted Mielczarek [:ted] from comment #5)
> We have tests on 10.7, and those tests are failing.

With 11.4 in the wild now, it's possible that we have a major blind spot here (for >2million Firefox users on 10.7/10.8). It'd be really good to get this fixed on test branches as soon as possible, and then in FF16 for the first time on release.
Assignee: nobody → ted.mielczarek
tracking-firefox16: ? → +
tracking-firefox17: --- → +
tracking-firefox18: --- → +
(Assignee)

Comment 7

5 years ago
Fixing this bug requires either updating our local Breakpad snapshot or finding the upstream patch that fixed this and cherrypicking it. I spent a while trying to find what fixed this upstream and had no success. Updating our Breakpad snapshot is going to require some effort, since we're about 2 years out of date (we've been cherrypicking patches), and we have a couple of sizable local patches that haven't been upstreamed (mostly my fault, work in support of OOP crash reporting that landed while I was on paternity leave and just haven't been able to dedicate time to upstreaming).

I'll try to make time this week to update our Breakpad.
(Assignee)

Updated

5 years ago
Depends on: 791775

Comment 8

5 years ago
This is server side as opposed to in-product. We'll continue to track for 17/18 to keep this on our radar, but we'll take this off of the FF16 tracking list.
tracking-firefox16: + → -

Comment 9

5 years ago
bsmedberg let me know this is in-product, and I should have noticed bug 791775
tracking-firefox16: - → +

Comment 10

5 years ago
There's no way we can fix this for 16, and it's really not safe enough for 17 either.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #10)
> There's no way we can fix this for 16, and it's really not safe enough for
> 17 either.

Alright - we can rely upon the crash data in FF18 on Nightly/Aurora to try to make remaining Flash crashes more actionable in the short term.
tracking-firefox16: + → -
tracking-firefox17: + → -
(Assignee)

Comment 12

5 years ago
This should be fixed in Nightly.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18

Updated

5 years ago
status-firefox18: --- → fixed
You need to log in before you can comment on or make changes to this bug.