This bug was filed from the Socorro interface and is report bp-9b7655cf-93dc-4c6f-a724-369ca2110823 . ============================================================= bp-4fefe504-000f-4466-bc1a-e462c2110823 is the same thing, but reported as a hang, both times this happens in the plugin process and is new on 9.0a1 trunk since the Nightly on 2011-08-17. The following lists give you more reports with those signatures if needed: https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char%20const%2A%20const%29%20%7C%20NS_DebugBreak_P%20%7C%20mozilla%3A%3Aplugins%3A%3APluginModuleChild%3A%3AShouldContinueFromReplyTimeout%28%29 https://crash-stats.mozilla.com/report/list?signature=hang%20%7C%20mozalloc_abort%28char%20const%2A%20const%29%20%7C%20NS_DebugBreak_P%20%7C%20mozilla%3A%3Aplugins%3A%3APluginModuleChild%3A%3AShouldContinueFromReplyTimeout%28%29 The stacks in both crash and hang cases are the same, here are the top 10 frames: 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:77 1 xul.dll NS_DebugBreak_P xpcom/base/nsDebugImpl.cpp:345 2 xul.dll mozilla::plugins::PluginModuleChild::ShouldContinueFromReplyTimeout dom/plugins/ipc/PluginModuleChild.cpp:531 3 xul.dll mozilla::ipc::SyncChannel::ShouldContinueFromTimeout ipc/glue/SyncChannel.cpp:264 4 xul.dll mozilla::ipc::SyncChannel::Send ipc/glue/SyncChannel.cpp:129 5 xul.dll mozilla::ipc::RPCChannel::Send ipc/glue/RPCChannel.cpp:150 6 xul.dll mozilla::plugins::PPluginInstanceChild::SendShow obj-firefox/ipc/ipdl/PPluginInstanceChild.cpp:863 7 xul.dll mozilla::plugins::PluginInstanceChild::ShowPluginFrame dom/plugins/ipc/PluginInstanceChild.cpp:3203 8 xul.dll mozilla::plugins::PluginInstanceChild::InvalidateRectDelayed dom/plugins/ipc/PluginInstanceChild.cpp:3271 9 xul.dll MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:345 (#10 and below are just message loop and starting of plugin-container.exe) This must have regressed in checkins on August 16th, right after 8 was taken to Aurora - given that we don't have any occurrences on 8.0a1 Nightlies or Aurora, it must have been a landing between the code uplift and the generation of the next nightly build.

This is the #1 report on 9.0a1 trunk now.

Also occurs on Nightly 10.0a1 bp-dd484740-2205-4002-9cd2-5c7c92111106, it crashed without popping up an "Error Reporter". My "Crashing Thread" originated in NPSWF32.dll and that is (possibly) Bug 698317.

(In reply to Rob from comment #3) > Also occurs on Nightly 10.0a1 bp-dd484740-2205-4002-9cd2-5c7c92111106, it > crashed without popping up an "Error Reporter". > > My "Crashing Thread" originated in NPSWF32.dll and that is (possibly) Bug > 698317. Also (each slightly different) on Nightly 10.0a1, bp-83309217-b244-48f7-8f61-af0032111106, bp-df922218-aa1a-488d-b14c-8c0ac2111106 and bp-c089ef5d-8c4d-4e93-bc7a-f9b6d2111106.

I believe I just hit this crash too. The browser froze and its CPU usage seemed stuck at a high level (reporting 13% on an 8-core machine, which would mean one core was being used at 100%). I had to kill the process and restart. I am running the nightly-ash build. https://crash-stats.mozilla.com/report/index/bp-e9592401-77b3-41f8-a15a-fb64c2111114 https://crash-stats.mozilla.com/report/index/bp-87990d66-f715-4569-b4f1-baa692111114

It's #1 top crasher in the latest nightly builds.

jimm, I'll not change it here but there's no real reason to remove crash sigs when duping, Socorro will show that it's a dupe anyhow and will also show the other bug if it has that sigs added.

(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #8) > jimm, I'll not change it here but there's no real reason to remove crash > sigs when duping, Socorro will show that it's a dupe anyhow and will also > show the other bug if it has that sigs added. Currently socorro/crash stats doesn't do a good job of organizing bugs listed in the Bugzilla IDs column of crash stats reporting. So I cleared everything so that 680130 was the main bug listed. (Maybe we should file a bug on this..) Also, the "More" drop down is pretty broken, so anything that falls into that is often ignored, which might explain why we ended up with so many dupes for this signature.