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)
Tracking
()
VERIFIED
FIXED
mozilla2.0b9
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
People
(Reporter: marcia, Assigned: ted)
Details
Attachments
(1 file)
163.47 KB,
image/png
|
Details |
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•14 years ago
|
blocking2.0: --- → ?
Assignee | ||
Comment 1•14 years ago
|
||
If you can find STR I can investigate this.
Comment 2•14 years ago
|
||
I don't think we want to ship Firefox 4 w/o reliable crash reporting for plugins, blocking.
blocking2.0: ? → final+
Reporter | ||
Comment 3•14 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•14 years ago
|
||
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
Assignee | ||
Comment 6•14 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)
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•14 years ago
|
Flags: in-litmus?
Comment 9•14 years ago
|
||
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)
Comment 10•14 years ago
|
||
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...
Comment 11•14 years ago
|
||
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•14 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•14 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•14 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•14 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•14 years ago
|
Component: Networking: WebSockets → Breakpad Integration
Product: Core → Toolkit
QA Contact: plugins → breakpad.integration
Target Milestone: mozilla2.0b7 → ---
Assignee | ||
Comment 16•14 years ago
|
||
Patch is up for review upstream: http://breakpad.appspot.com/241001/show
Assignee | ||
Comment 17•14 years ago
|
||
Landed upstream: http://code.google.com/p/google-breakpad/source/detail?r=746 Will land on m-c shortly.
Assignee | ||
Comment 18•14 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•14 years ago
|
||
Landed upstream: http://code.google.com/p/google-breakpad/source/detail?r=747
Assignee | ||
Comment 20•14 years ago
|
||
Pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/2020888cd34f
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Comment 21•14 years ago
|
||
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.
Description
•