Closed Bug 590961 Opened 14 years ago Closed 14 years ago

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

Categories

(Toolkit :: Crash Reporting, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla2.0b9
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: marcia, Assigned: ted)

Details

Attachments

(1 file)

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.
blocking2.0: --- → ?
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+
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.
Without STR, I think it's very hard to block on this.
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
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)
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).
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).
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
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.
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.
Component: Networking: WebSockets → Breakpad Integration
Product: Core → Toolkit
QA Contact: plugins → breakpad.integration
Target Milestone: mozilla2.0b7 → ---
Patch is up for review upstream:
http://breakpad.appspot.com/241001/show
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
Pushed to m-c:
http://hg.mozilla.org/mozilla-central/rev/2020888cd34f
Status: NEW → RESOLVED
Closed: 14 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.

Attachment

General

Created:
Updated:
Size: