This bug was filed from the Socorro interface and is report bp-3ac6f8ab-dd9e-44f7-90d7-7a2382110715 . ============================================================= I've now received this crash twice (see also https://crash-stats.mozilla.com/report/index/bp-4b1d89fa-103e-4c75-bff4-201f42110715). The Flash plugin is now intermittently crashing on the latest trunk updates under Ubuntu 11.04.
I've noticed this a lot, as well. It seems to crash for no obvious reason, even when flash isn't running. Started on July 13, maybe a regression? I'll look into a range.
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%20%7C%20NS_DebugBreak_P%20%7C%20X11Error Frame Module Signature [Expand] Source 0 libmozalloc.so mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:66 1 libxul.so NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:388 2 libxul.so X11Error toolkit/xre/nsX11ErrorHandler.cpp:199 3 libX11.so.6.3.0 libX11.so.6.3.0@0x3b298 4 libX11.so.6.3.0 libX11.so.6.3.0@0x4192e 5 libX11.so.6.3.0 libX11.so.6.3.0@0x41fb5 6 libX11.so.6.3.0 libX11.so.6.3.0@0x35846 7 libxul.so mozilla::plugins::PluginInstanceChild::ShowPluginFrame dom/plugins/ipc/PluginInstanceChild.cpp:3174 8 libxul.so mozilla::plugins::PluginInstanceChild::InvalidateRectDelayed dom/plugins/ipc/PluginInstanceChild.cpp:3271 9 libxul.so RunnableMethod<mozilla::plugins::PluginInstanceChild, void , Tuple0>::Run ipc/chromium/src/base/tuple.h:383 10 libxul.so MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:342 11 libxul.so MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:450 12 libxul.so base::MessagePumpForUI::RunWithDispatcher ipc/chromium/src/base/message_pump_glib.cc:199 13 libxul.so base::MessagePumpForUI::Run ipc/chromium/src/base/message_pump_glib.h:59 14 libxul.so MessageLoop::Run ipc/chromium/src/base/message_loop.cc:218 15 libxul.so XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:510 16 plugin-container main ipc/app/MozillaRuntimeMain.cpp:81 17 libc-2.11.1.so libc-2.11.1.so@0x16bd5 18 plugin-container plugin-container@0xe40 19 plugin-container plugin-container@0xeff 20 ld-2.11.1.so ld-2.11.1.so@0xe02f 21 ld-2.11.1.so ld-2.11.1.so@0x1c8f7
This seems to happen with a whole range of Linux (kernel) versions, so it's also not a single person or distro, must be more generic. Also, it's 8.0a1-trunk-only and first started happening on 2011-07-13 versions. Who is a Linux dev guy we could get into the loop here? Any Linux-specific checkins on the 12th or perhaps 13th that could have triggered that?
Possible pushlog regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8753de11b181&tochange=931f06b80727. There was a merge from mozilla inbound that day.
Karl, bsmedberg, I wasn't sure who could help with this bug but dbaron suggested I cc you both. This crash started showing up on 7/13. Any ideas?
(In reply to comment #4) > Possible pushlog regression range: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=8753de11b181&tochange=931f06b80727. Marcia, it could also be in the next "slot" of nightly, as it's possible that those very few reports from 13th build IDs were on "hourly" builds. A looking at http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2011-07-12&enddate=2011-07-14 I see some very X11/GTK-specific changesets at the top of the list. Ginn, could one of your changes be related?
It's a day when beta version of flash 11 has been released. :-) http://labs.adobe.com/downloads/flashplayer11.html
(In reply to comment #7) > It's a day when beta version of flash 11 has been released. :-) > http://labs.adobe.com/downloads/flashplayer11.html That's an interesting data point, but unfortunately doesn't explain why this happens on 8.0a1 only and not on any other versions.
Bug 644707 is the reason why we see this as a SIGSEGV only on 8.
We aren't getting any data about Flash versions for this one so we can't correlate it specifically to Flash 11. It's the top plugin crash on the trunk right now.
I'm still getting this crash with Flash 10.3.181.34, so it's definitely not Flash Player 11-specific (if at all).
Are there any console messages to indicate the X Error? Do you have steps to reproduce.(In reply to comment #10) > We aren't getting any data about Flash versions FWIW we can map the debug identifier for libflashplayer.so to versions.
When I try to track this down using Linux I end up in a Mac OS X bug. Anyway, this is what I've found using FlashPlayer 220.127.116.11: bp-128a6a3b-242c-42d6-8842-c99842110809 [@ mozalloc_abort | NS_DebugBreak_P | X11Error ] Last good nightly: 2011-07-13 First bad nightly: 2011-07-14 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=931f06b80727&tochange=34b0b3bc6984 The first bad revision is: changeset: 72713:5cea57e451dd user: Benoit Girard <firstname.lastname@example.org> date: Tue Jul 12 10:31:18 2011 -0400 summary: Bug 663259 - Enable Mac Async plugin by default. r=cjones,mattwoodrow http://hg.mozilla.org/mozilla-central/rev/5cea57e451dd ------- STR: 1. Visit http://chessinkorea.com/xe/3959 with a new, clean profile 2. Shake the right scroll bar fast for 20 seconds Actual Results: FlashPlayer crash Expected Results: No FlashPlayer crash
Thanks very much, Thomas!
Thanks for finding the regression range! The problem is here: http://hg.mozilla.org/mozilla-central/rev/5cea57e451dd#l6.228 I will post a patch first thing in the morning and will spin off a try build.
Created attachment 552071 [details] [diff] [review] patch v1 See: http://hg.mozilla.org/mozilla-central/rev/5cea57e451dd#l6.228 This line was not meant to be changed for non osx platforms.
Can someone confirm that the problem is fixed before we land this? Try builds: https://email@example.com/
I've tested https://firstname.lastname@example.org/try-linux64/firefox-8.0a1.en-US.linux-x86_64.tar.bz2 together with the STR from comment 13 and have NOT been able to reproduce the bug. Thus, it looks fixed to me.
So technically we still see this crash in recent builds but the volume is way down. I don't see a reason to track this. + 9.0a1 - 7 crashes in the past 2 weeks. + 8.0a2 - 3 crashes in the past 2 weeks.
(In reply to Sheila Mooney from comment #22) > So technically we still see this crash in recent builds but the volume is > way down. I don't see a reason to track this. Yes, the fix landed for 8, so we should be OK. The remaining ones are probably not this regression at least (or it's old builds).