Seen while looking at trunk crash stats. Crashes started showing up using the 2011083000 build. https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char%20const*%20const%29%20|%20msvcr80.dll@0xe456 Possible pushlog regression range based on crash stats: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=33031c875984&tochange=e6591ea9b27b Frame Module Signature [Expand] Source 0 mozalloc.dll mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:77 1 msvcr80.dll msvcr80.dll@0xe456 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:3266 8 xul.dll mozilla::plugins::PluginInstanceChild::InvalidateRectDelayed dom/plugins/ipc/PluginInstanceChild.cpp:3334 9 xul.dll MessageLoop::RunTask ipc/chromium/src/base/message_loop.cc:318 10 xul.dll MessageLoop::DeferOrRunPendingTask ipc/chromium/src/base/message_loop.cc:326 11 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:426 12 xul.dll base::MessagePumpForUI::DoRunLoop ipc/chromium/src/base/message_pump_win.cc:214 13 xul.dll base::MessagePumpWin::RunWithDispatcher ipc/chromium/src/base/message_pump_win.cc:53 14 xul.dll base::MessagePumpWin::Run ipc/chromium/src/base/message_pump_win.h:78 15 xul.dll MessageLoop::RunInternal ipc/chromium/src/base/message_loop.cc:208 16 xul.dll MessageLoop::RunHandler 17 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:175 18 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp:512 19 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp:107 20 plugin-container.exe __tmainCRTStartup crtexe.c:594 21 kernel32.dll BaseThreadInitThunk 22 ntdll.dll __RtlUserThreadStart 23 ntdll.dll _RtlUserThreadStart
Possible dupe of Bug 680130?
No, not a dupe. Bug 680130 is for the new type of signature that can appear in crashes, and this is an example of such a signature.
After a while on this site: http://davidwalsh.name/gmail-php-imap I crashes with the above signature
mozalloc_abort(char const* const) | _RTC_Terminate plugin signature started appearing in the same time frame so it is likely related.
I get this crash playing games on google+. I leave the game open when putting the computer to sleep, after waking up the computer the plugin crashes.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #6) > Comment 5 is a situation that jimm and I discussed and we need to fix. bug 679240 was filed on that. Not surprising the frequency of this problem would increase now that we are looking for timeouts on both sides of the connection.
Created attachment 561294 [details] See comment 8 for more details With last nightly i have problem with playing video when opened at least 2-3 tabs with Youtube and pause each video for buffering. After few seconds, all the video starts playing in the background and also the plugin container have memory leak when growth to about 900-1500MB it crashes the Nvidia video driver that sometimes don't properly recover. Crash signature point to these bug https://crash-stats.mozilla.com/report/index/bp-5ab369ac-867f-46c7-a983-d3ab52110920
Hello, I had bug 566062 and was told to try nightly. Nightly did the same thing and had adobe flash player crash. https://crash-stats.mozilla.com/report/index/bp-cde24d56-e1a0-4326-a8f9-01d022111001 Thank You
I still get this crash all the time but 99% of my 30 crash reports fail to submit.
It's #15 top crasher in 9.0b2.
Dupe of bug 681385?
Not tracking for Firefox 9.
#14 crash for both 9.0b2 and 9.0b3 (In reply to Scoobidiver from comment #13) > Dupe of bug 681385? seems likely, given that this signature picks up where mozalloc_abort(char const* const) | NS_DebugBreak_P | mozilla::plugins::PluginModuleChild::ShouldContinueFromReplyTimeout() dies out https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=exact&query=mozalloc_abort%28char%20const*%20const%29%20|%20NS_DebugBreak_P%20|%20mozilla%3A%3Aplugins%3A%3APluginModuleChild%3A%3AShouldContinueFromReplyTimeout%28%29&reason_type=contains&date=10%2F02%2F2011%2004%3A01%3A16&range_value=16&range_unit=weeks&hang_type=any&process_type=any&do_query=1&admin=1&signature=mozalloc_abort%28char%20const*%20const%29%20|%20NS_DebugBreak_P%20|%20mozilla%3A%3Aplugins%3A%3APluginModuleChild%3A%3AShouldContinueFromReplyTimeout%28%29 is Bug 680130 actually going to be a meta bug?
Getting this consistently when loading Words With Friends on Facebook in 10b1 on XP, the last 9 beta never did this. On my third attempt however I noticed that despite the crash it still works, and if anything I think the performance might be better than before.
This is sitting at #18 on 9.0.1 but at #2 on 10.0b2 with pretty high volume - over 10K in a week. I think we need to get someone on it.
This appears to be the intentional crash when a plugin detects that its parent (Firefox) process is not responding. That code was disabled on previous release branches, and until we can get matching browser-side stacks for the hangs (bug 679238) we should probably continue disabling this for release branches.
(In reply to Benjamin Smedberg [:bsmedberg] from comment #18) > This appears to be the intentional crash when a plugin detects that its > parent (Firefox) process is not responding. That code was disabled on > previous release branches, and until we can get matching browser-side stacks > for the hangs (bug 679238) we should probably continue disabling this for > release branches. Lets just disable it on trunk until the issues with the crash reporter code can be worked out. These crashes aren't telling us anything without parent side stacks. I'll work up a patch and post it here.
Created attachment 585823 [details] [diff] [review] patch
Comment on attachment 585823 [details] [diff] [review] patch Disabling some crash generation code that has in the past been enabled on trunk but not branch.
I realize that work is going on to disable this, but I did hit this crash yesterday in the lab while testing Facebook: https://crash-stats.mozilla.com/report/index/bp-b06c36c7-774d-4d97-abfc-b84492120104. I had a Facebook game loaded, left the computer for several hours, and when I came back I got this crash. I mentioned this to smooney during the meeting since at that time she was looking for STR for this crash.
(In reply to Marcia Knous [:marcia] from comment #22) > I realize that work is going on to disable this, but I did hit this crash > yesterday in the lab while testing Facebook: > https://crash-stats.mozilla.com/report/index/bp-b06c36c7-774d-4d97-abfc- > b84492120104. > > I had a Facebook game loaded, left the computer for several hours, and when > I came back I got this crash. I mentioned this to smooney during the meeting > since at that time she was looking for STR for this crash. Was the system suspended (in sleep or hibernate mode) when you came back?
Comment on attachment 585823 [details] [diff] [review] patch [Triage Comment] Approved for Aurora. From https://bugzilla.mozilla.org/show_bug.cgi?id=683967#c17 though, it sounds like FF10 is also affected. Should the patch land there as well?
It surely affects 10 as well, I have seen it high up throughout its aurora and beta lifetime. I think the patch needs to go into beta as well.
Comment on attachment 585823 [details] [diff] [review] patch Yep, we need this in 10 as well.
https://hg.mozilla.org/mozilla-central/rev/5413ba3ed406 https://hg.mozilla.org/releases/mozilla-aurora/rev/2f332e07843a still need beta approval. Note, I'm closing this bug out, but this crash will likely remain for other reasons. So we'll likely need to create a new bug for this once crash stats settles down.
Comment on attachment 585823 [details] [diff] [review] patch [Triage Comment] Approved for beta as well, based upon low risk vs high reward of mitigating this regression.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 No reports for any 11 beta in the last 4 weeks with this crash signature: http://bit.ly/w3QKKN Also tried playing google plus games and visiting sites which were reported to have crashed Firefox with this signature(comment 3, 5, 12). No crashes.