Closed Bug 595278 Opened 14 years ago Closed 13 years ago

Crash in [@ js::DeepBail ] when clicking "Skip" in video

Categories

(Core :: JavaScript Engine, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- betaN+

People

(Reporter: marcia, Assigned: luke)

References

()

Details

(Keywords: crash, Whiteboard: [softblocker][fixed-in-tracemonkey])

Crash Data

Attachments

(1 file)

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.
blocking2.0: --- → ?
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 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)
blocking2.0: ? → betaN+
Currently bisecting TM builds. The regressing change landed Jul 22 to TM.
Assignee: general → dmandelin
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
Assignee: dmandelin → general
Blocks: 552266
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.
Assignee: general → lw
Whiteboard: softblocker
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.
Attached patch maybe fixSplinter Review
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.
Attachment #503220 - Flags: review?(jst)
Attachment #503220 - Flags: review?(jst) → review+
(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.
http://hg.mozilla.org/tracemonkey/rev/5ad016df10fe
Whiteboard: softblocker → [softblocker][fixed-in-tracemonkey]
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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Crash Signature: [@ js::DeepBail ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: