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 <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 <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 <Error>: kCGErrorInvalidOperation: _CGSFindSharedWindow: WID 934 8/26/10 9:56:43 AM plugin-container 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.
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.
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.
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).
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).
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
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.
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.
Patch is up for review upstream: http://breakpad.appspot.com/241001/show
Landed upstream: http://code.google.com/p/google-breakpad/source/detail?r=746 Will land on m-c shortly.
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
Landed upstream: http://code.google.com/p/google-breakpad/source/detail?r=747
Pushed to m-c: http://hg.mozilla.org/mozilla-central/rev/2020888cd34f
Verified fixed based on my testcase on bug 619757.