Seen while running Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre. I can reproduce on a Win XP VM, but I don't get a crash - instead I get a MS dialog saying the plugincontainer crashed. On both machines I was running Flash Version: 10.1.82.76. STR: 1. Load http://n.yam.com/view/mkvideopage.php/20100910175898 2. Click on "Skip" (in the flash video) 3. I crash 100% using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100910 Firefox/4.0b6pre https://crash-stats.mozilla.com/report/index/866d5c19-2b20-447b-bf58-c11902100910 is my report. Frame Module Signature [Expand] Source 0 XUL js::DeepBail js/src/jstracer.cpp:8037 1 XUL StopRequest js/src/jscntxt.h:3172 2 XUL mozilla::plugins::parent::_evaluate jsapi.h:750 3 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x49264d 4 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x495b65 5 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0xd63c0 6 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x334d47 7 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x260817 8 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x25ce7a 9 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x420caf 10 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x421a5e 11 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x49f69d 12 FlashPlayer-10.4-10.5 FlashPlayer-10.4-10.5@0x417429 13 XUL nsNPAPIPluginInstance::HandleEvent modules/plugin/base/src/nsNPAPIPluginInstance.cpp:590 14 XUL nsPluginInstanceOwner::ProcessEvent layout/generic/nsObjectFrame.cpp:4657 15 XUL nsPluginInstanceOwner::MouseDown layout/generic/nsObjectFrame.cpp:4059 16 XUL nsEventListenerManager::HandleEventInternal content/events/src/nsEventListenerManager.cpp:175 17 XUL nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventListenerManager.h:146 18 XUL nsEventDispatcher::Dispatch content/events/src/nsEventDispatcher.cpp:628 19 XUL PresShell::HandleEventInternal layout/base/nsPresShell.cpp:6752 20 XUL PresShell::HandlePositionedEvent layout/base/nsPresShell.cpp:6594 21 XUL PresShell::HandleEvent layout/base/nsPresShell.cpp:6444 22 XUL nsViewManager::DispatchEvent view/src/nsViewManager.cpp:1120 23 XUL HandleEvent view/src/nsView.cpp:161 24 XUL nsChildView::DispatchEvent widget/src/cocoa/nsChildView.mm:1715 25 XUL nsChildView::DispatchWindowEvent widget/src/cocoa/nsChildView.mm:1725 26 XUL -[ChildView mouseDown:] widget/src/cocoa/nsChildView.mm:3108 27 AppKit -[NSWindow sendEvent:] 28 XUL -[ToolbarWindow sendEvent:] widget/src/cocoa/nsCocoaWindow.mm:2339 29 AppKit -[NSApplication sendEvent:] 30 AppKit -[NSApplication run] 31 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:747 32 XUL nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:191 33 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3665 34 firefox-bin main browser/app/nsBrowserApp.cpp:158 35 firefox-bin firefox-bin@0xbe5 36 @0x1

Adding juanb to see if he can get the same result on 10.6.

I don't get a crash using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8, but the page lays out quite a bit different and seems to show 2 videos. The video I am clicking "Skip" on is the car video.

One other crash report I see in crash stats indicated someone crashed on 10.6 as well -> http://crash-stats.mozilla.com/report/index/860e8377-fff2-4dc0-9f8a-c72052100909.

I crashed on 10.6 as well, see http://crash-stats.mozilla.com/report/index/e2e79aad-2db0-4b63-bf4c-b99c42100915.

I can reproduce a crash here on Linux. The |cx| is invalid in StopRequest, all its members have been painted over with 0x5a, which looks like a free pattern in jemalloc.

Crashes on WinXP using a Build built from http://hg.mozilla.org/mozilla-central/rev/7640eb022be6 Frame Module Signature Source 0 xul.dll StopRequest js/src/jsapi.cpp:851 1 xul.dll mozilla::plugins::parent::_evaluate(_NPP*,NPObject*,_NPString*,_NPVariant*) modules/plugin/base/src/nsNPAPIPlugin.cpp:1641 2 xul.dll mozilla::plugins::PluginScriptableObjectParent::AnswerNPN_Evaluate(nsCString const&,mozilla::plugins::Variant*,bool*) dom/plugins/PluginScriptableObjectParent.cpp:1234 3 xul.dll mozilla::plugins::PPluginScriptableObjectParent::OnCallReceived(IPC::Message const&,IPC::Message*&) obj-firefox/ipc/ipdl/PPluginScriptableObjectParent.cpp:692 4 xul.dll mozilla::plugins::PPluginModuleParent::OnCallReceived(IPC::Message const&,IPC::Message*&) obj-firefox/ipc/ipdl/PPluginModuleParent.cpp:596 5 xul.dll mozilla::ipc::RPCChannel::DispatchIncall(IPC::Message const&) ipc/glue/RPCChannel.cpp:517 6 xul.dll mozilla::ipc::RPCChannel::Incall(IPC::Message const&,unsigned int) ipc/glue/RPCChannel.cpp:503 7 xul.dll mozilla::ipc::RPCChannel::OnMaybeDequeueOne() ipc/glue/RPCChannel.cpp:434 8 xul.dll MessageLoop::RunTask(Task*) ipc/chromium/src/base/message_loop.cc:343 9 xul.dll MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) ipc/chromium/src/base/message_loop.cc:351 10 xul.dll MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc:451 11 xul.dll mozilla::ipc::DoWorkRunnable::Run() ipc/glue/MessagePump.cpp:70 12 xul.dll nsThread::ProcessNextEvent(int,int*) xpcom/threads/nsThread.cpp:547 13 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:134 14 xul.dll xul.dll@0xbf8bb7 15 xul.dll MessageLoop::RunInternal() ipc/chromium/src/base/message_loop.cc:219 16 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:202 17 xul.dll _SEH_epilog4 18 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:176 19 xul.dll nsBaseAppShell::Run() widget/src/xpwidgets/nsBaseAppShell.cpp:180 20 xul.dll nsAppShell::Run() widget/src/windows/nsAppShell.cpp:243 21 nspr4.dll PR_LogPrint nsprpub/pr/src/io/prlog.c:525)

Hmpf, should say "Build built from http://hg.mozilla.org/tracemonkey/rev/dfcf5611ce02"

Currently bisecting TM builds. The regressing change landed Jul 22 to TM.

The regressing changeset is: changeset: 48013:70257f457819 user: Igor Bukanov <igor@mir2.org> date: Fri Jul 23 13:33:15 2010 +0200 summary: bug 552266 - - asserting that autorooters are used only under a request. r=mrbkap

Within the last 4 weeks, there have been 57 crashes on Mac - see http://tinyurl.com/32s2lrw. There doesn't appear to have been any crashes in Beta 7 in this stack - all are either B6 crashes or crashes in earlier betas.

Seems significant. Igor, do you have time for this or do you need some help?

Luke said he'd take a crack at this.

The #25 top crash on the trunk is a very similar stack: [@ js::DeepBail(JSContext*) ] Do we think this is the same bug or should I file a new one? http://tinyurl.com/34xeot5 links to those reports.

(In reply to comment #13) > The #25 top crash on the trunk is a very similar stack: > [@ js::DeepBail(JSContext*) ] > > Do we think this is the same bug or should I file a new one? > > http://tinyurl.com/34xeot5 links to those reports. Please file a new one--I hope they turn out to be the same, but on casual inspection they seem to be different.

Getting this under a debugger, it looks like the assert is not actually in DeepBail, but rather in StopRequest which tries to access a member of cx->thread which is null.

More info: cx->thread is cleared by a call to js_DestroyContext, called by nsXPCOnnect::ReleaseJSContext. Hard to get gdb to tell me more from this optimized nightly. I am finally able to get a local build to crash (using the nightly's .mozconfig and running the i386 build on OS X 10.6) so hopefully I can actually do useful debugging now.

So the context is being destroyed when the nsCOMPtr<nsIScriptContext> goes out of scope which, since it is declared right before the JSAutoRequest, destroys the context right before ~JSAutoRequest tries to end the request. The attached patch makes the crash go away. Seems like a simple fix, but question for jst: does it make sense that the nsIScriptContext returned by GetScriptContextFromJSContext ends up with no other outstanding references at the end of _evaluate? I am just asking to make sure this fix isn't just papering over some bug somewhere else.

(In reply to comment #17) > Seems like a simple fix, but question for jst: does it make sense that the > nsIScriptContext returned by GetScriptContextFromJSContext ends up with no > other outstanding references at the end of _evaluate? I am just asking to make > sure this fix isn't just papering over some bug somewhere else. Yes, I could see that happening with NPAPI, a plugin could evaluate code that ends up closing the window it's in or what not, which I think could lead to exactly that.

I still see some crashes with the StopRequest crash signature: bp-5813df74-5dee-4146-b1ce-c69902110116 bp-8ff49fa8-ef12-4ac2-9fd5-de3742110116

This hasn't been merged to m-c yet.

cdleary-bot mozilla-central merge info: http://hg.mozilla.org/mozilla-central/rev/5ad016df10fe