[Mac] OOPP: Don't get crash reports from 32-bit plugins in 64-bit Firefox

VERIFIED FIXED in mozilla2.0b9

Status

()

Toolkit
Breakpad Integration
--
critical
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: marcia, Assigned: ted)

Tracking

Trunk
mozilla2.0b9
x86_64
Mac OS X
Points:
---
Bug Flags:
in-testsuite ?
in-litmus ?

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 469509 [details]
Screenshot of crash page

Using Flash Version: 10.1.82.76 and Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b5pre) Gecko/20100826 Minefield/4.0b5pre, I crashed but I got a "No Report Available." 

STR:
1. Crash while playing a hulu.com video. I might have "Popped Out" the video player before the crash.
2. Get the attached screenshot

Some stuff from the console:

8/26/10 9:51:49 AM	[0x0-0x1e01e].org.mozilla.firefox	Thu Aug 26 09:51:49 host-5-35.mv.mozilla.com firefox-bin[6582] <Error>: kCGErrorInvalidOperation: _CGSFindSharedWindow: WID 934
8/26/10 9:51:49 AM	[0x0-0x1e01e].org.mozilla.firefox	Thu Aug 26 09:51:49 host-5-35.mv.mozilla.com firefox-bin[6582] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
8/26/10 9:51:49 AM	[0x0-0x1e01e].org.mozilla.firefox	Thu Aug 26 09:51:49 host-5-35.mv.mozilla.com firefox-bin[6582] <Error>: kCGErrorInvalidOperation: _CGSFindSharedWindow: WID 934
8/26/10 9:56:43 AM	plugin-container[6583]	Warning once: This application, or a library it uses, is using NSQuickDrawView, which has been deprecated. Apps should cease use of QuickDraw and move to Quartz.
(Reporter)

Updated

7 years ago
blocking2.0: --- → ?
(Assignee)

Comment 1

7 years ago
If you can find STR I can investigate this.
I don't think we want to ship Firefox 4 w/o reliable crash reporting for plugins, blocking.
blocking2.0: ? → final+
(Reporter)

Comment 3

7 years ago
Unfortunately I haven't seen this since the initial report. But I test OOPP every day on the Mac so I will keep a watchful eye.
(Assignee)

Comment 4

7 years ago
Without STR, I think it's very hard to block on this.

Comment 5

7 years ago
This bug says x86, but for me it only happens on x86-64 Firefox process. I can't recall ever having a crash report for Flash since firefox-bin became a i386/x86-64 binary.

Anyways:

While watching my YouTube subscriptions earlier today the plugin would crash without any report if I navigated to the next video (or any new page) while the video was still playing.

Running Firefox in 32-bit mode instead of the default 64-bit gave me this crash report doing the same thing:

http://crash-stats.mozilla.com/report/index/714134b6-296b-4b34-9632-9159e2101101
http://crash-stats.mozilla.com/report/index/5dc55a32-ba3b-4dd9-9d2a-f70fd2101101

Also happens when viewing a playlist, like this one:
http://www.youtube.com/view_play_list?p=825EE416379D8F72&playnext=1

Report:
http://crash-stats.mozilla.com/report/index/a45e1748-39dc-4756-b7db-ba1f22101101

My Flash version is 10,1,85,3
(Assignee)

Comment 6

7 years ago
Thanks, that's useful info. I don't know that crash reporting was tested with a 64-bit Firefox and a 32-bit plugin. I'll look into this.
Assignee: nobody → ted.mielczarek
Summary: [Mac] OOPP: Not always getting report when I crash in OOPP Flash → [Mac] OOPP: Not always getting report when I crash in OOPP Flash (using 32-bit Flash plugin on 64-bit Firefox)

Comment 7

7 years ago
FWIW I didn't get any crash reports with 64-bit Firefox and 64-bit plugin either while I was testing it.

I went back to the 32-bit plugin in part because the fullscreen didn't work (see bug 607023)
Ted, that's my setup too (64-bit Firefox, 32-bit plugins).
(Reporter)

Updated

7 years ago
Flags: in-litmus?
Marcia, I'll add the manual test here and in litmus later when we have a good set in the spreadsheet: https://spreadsheets.google.com/ccc?key=0Ar0rkj-NjT-WdEdUU1VFbk95YU5jV1JpeEFxMnNNaGc&authkey=CKrD6tUN&hl=en#gid=0

(anyone else is welcome to add tests there or comment)
Hy everyone, these are my proposals for Litmus tests 

https://spreadsheets.google.com/ccc?key=0AlsgObMBZ381dFo3cDlwNk5EaU5JLXdId0U5RXNaNXc&hl=en#gid=0

unfortunately it needs more investigating. 

I can't reproduce Marcia's problem since hulu.com videos are not available outside the US...
We should try to fix this in one of the betas to get an idea of these types of crashes.

While they are not the same as a browser crash, they are disruptive to the user experience, and there might be things we can do to improve that, or contact the right people at Adobe to alert them before a lot more users see this.

It's not uncommon for me to experience this problem (I can't reproduce on command).

Comment 12

7 years ago
I've been able to reproduce the Flash Plugin crashing quite easily: 

1. Begin watching any YouTube video with the new player
2. Navigate away from the video page while the video is playing
3. Flash will crash.

My crash reports, all occurred doing the above:
http://crash-stats.mozilla.com/report/index/bp-8da225e6-5116-4901-bc99-707f02101105
http://crash-stats.mozilla.com/report/index/bp-dc1a2e99-a726-4af3-b48d-a457f2101104

These ones point to bug 572134
http://crash-stats.mozilla.com/report/index/bp-e10d1770-6902-49e0-90da-2820a2101104
http://crash-stats.mozilla.com/report/index/bp-7bbbdad4-8274-4b99-98dd-664f62101104
http://crash-stats.mozilla.com/report/index/bp-ce6d9759-8766-4b1b-b026-da8112101104
http://crash-stats.mozilla.com/report/index/bp-51137f8a-95a4-47d7-b40f-4c0cf2101104
(Assignee)

Comment 13

7 years ago
Okay, so after doing some tests with the test plugin, it looks like we don't actually get crash reports at all from a 32-bit plugin running with a 64-bit browser.
blocking2.0: final+ → betaN+
Component: Plug-ins → Networking: WebSockets
Summary: [Mac] OOPP: Not always getting report when I crash in OOPP Flash (using 32-bit Flash plugin on 64-bit Firefox) → [Mac] OOPP: Don't get crash reports from 32-bit plugins in 64-bit Firefox
Target Milestone: --- → mozilla2.0b7

Comment 14

7 years ago
should this be moved up to beta9 ?   betaN means we not have time to get this working right in time to fix any problems that are hiding in missed crash reports.
(Assignee)

Comment 15

7 years ago
I'm about 50% through this. There are a large number of places in Breakpad where the OOP minidump generation code assumes it's dumping a process of the same CPU architecture, so fixing this involves refactoring a large amount of code.
(Assignee)

Updated

7 years ago
Component: Networking: WebSockets → Breakpad Integration
Product: Core → Toolkit
QA Contact: plugins → breakpad.integration
Target Milestone: mozilla2.0b7 → ---
(Assignee)

Comment 16

7 years ago
Patch is up for review upstream:
http://breakpad.appspot.com/241001/show
(Assignee)

Comment 17

7 years ago
Landed upstream:
http://code.google.com/p/google-breakpad/source/detail?r=746

Will land on m-c shortly.
(Assignee)

Comment 18

7 years ago
I tested this in the browser and it wasn't working, so I started writing more unit tests and found that I had missed a bit. That patch is up for review upstream:
http://breakpad.appspot.com/244001
(Assignee)

Comment 19

7 years ago
Landed upstream:
http://code.google.com/p/google-breakpad/source/detail?r=747
(Assignee)

Comment 20

7 years ago
Pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/2020888cd34f
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Verified fixed based on my testcase on bug 619757.
Status: RESOLVED → VERIFIED
Hardware: x86 → x86_64
Target Milestone: --- → mozilla2.0b9
You need to log in before you can comment on or make changes to this bug.