Closed Bug 1350738 Opened 5 years ago Closed 5 years ago

[e10s] Crash in mozilla::gfx::DrawTargetRecording::DrawTargetRecording


(Core :: Graphics, defect)

53 Branch
Not set



Tracking Status
firefox-esr45 --- unaffected
firefox52 --- unaffected
firefox-esr52 --- fixed
firefox53 --- fixed
firefox54 --- fixed
firefox55 --- fixed


(Reporter: philipp, Assigned: bobowen)



(Keywords: crash, regression, Whiteboard: [gfx-noted])

Crash Data

+++ This bug was initially created as a clone of Bug #1315212 +++

This bug was filed from the Socorro interface and is 
report bp-1ce13c02-b7d8-4089-9e0d-8b79f2170326.
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::gfx::DrawTargetRecording::DrawTargetRecording(mozilla::gfx::DrawEventRecorder*, mozilla::gfx::DrawTarget*, bool) 	gfx/2d/DrawTargetRecording.cpp:269
1 	xul.dll 	mozilla::gfx::Factory::CreateRecordingDrawTarget(mozilla::gfx::DrawEventRecorder*, mozilla::gfx::DrawTarget*) 	gfx/2d/Factory.cpp:363
2 	xul.dll 	nsSimplePageSequenceFrame::PrePrintNextPage(nsITimerCallback*, bool*) 	layout/generic/nsSimplePageSequenceFrame.cpp:637
3 	xul.dll 	nsPrintEngine::PrePrintPage() 	layout/printing/nsPrintEngine.cpp:2659
4 	xul.dll 	nsPagePrintTimer::Notify(nsITimer*) 	layout/printing/nsPagePrintTimer.cpp:156
5 	xul.dll 	nsTimerImpl::Fire(int) 	xpcom/threads/nsTimerImpl.cpp:482
6 	xul.dll 	nsTimerEvent::Run() 	xpcom/threads/TimerThread.cpp:297
7 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1240
8 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/glue/nsThreadUtils.cpp:390
9 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:124
10 	xul.dll 	mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:301
11 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/
12 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/
13 	xul.dll 	nsBaseAppShell::Run() 	widget/nsBaseAppShell.cpp:156
14 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp:262
15 	xul.dll 	XRE_RunAppShell() 	toolkit/xre/nsEmbedFunctions.cpp:924
16 	xul.dll 	mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:269
17 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/
18 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/
19 	xul.dll 	XRE_InitChildProcess(int, char** const, XREChildData const*) 	toolkit/xre/nsEmbedFunctions.cpp:756
20 	xul.dll 	mozilla::BootstrapImpl::XRE_InitChildProcess(int, char** const, XREChildData const*) 	toolkit/xre/Bootstrap.cpp:65
21 	firefox.exe 	content_process_main(mozilla::Bootstrap*, int, char** const) 	ipc/contentproc/plugin-container.cpp:115
22 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:115
23 	firefox.exe 	__scrt_common_main_seh 	f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:253
24 	kernel32.dll 	BaseThreadInitThunk 	
25 	ntdll.dll 	__RtlUserThreadStart 	
26 	ntdll.dll 	_RtlUserThreadStart 	

this e10s crash signature was fixed in bug 1315212 but it's resurfacing in the 53.0b cycle - it's accounting for 0.5% of content crashes:>%3D2016-09-26T20%3A32%3A38.000Z#graphs

Correlations for Firefox Beta
(99.31% in signature vs 00.05% overall) address = 0x39
(100.0% in signature vs 11.32% overall) reason = EXCEPTION_ACCESS_VIOLATION_READ
(100.0% in signature vs 21.65% overall) moz_crash_reason = null
(100.0% in signature vs 23.75% overall) graphics_startup_test = null
(100.0% in signature vs 23.76% overall) ipc_system_error = null
(100.0% in signature vs 00.07% overall) GFX_ERROR "Failed to create similar cairo surface! Size: " = true [69.70% vs 00.18% if startup_crash = null]
This is a different crash to bug 1315212, it is in a different constructor.
(Although, it is called directly after the previous one, so it is probably the same underlying cause where the CreateSimilarDrawTarget on the wrapped (non-recording) DrawTarget has failed.)

The code at [1] looks a little suspect anyway.
At the very least the creation of the DrawEventRecorder and call to CreateRecordingDrawTarget should go after the null check.

Also, if we are printing via the parent (which is starting to become the norm in all e10s case), then canvasTarget is already a DrawTargetRecording.
Wrapping it again seems a little weird and will possibly cause issues.

I would have thought that we could just use the normal printing DrawTargetRecording canvasTarget, but other code in that patch assumes that we have a DrawEventRecorderMemory, so something will probably break.
However, the original DrawTargetRecording (and its DrawEventRecorder) should already know about that SourceSurfaceRecording
so I'm not sure we would have to do any of the InlineTranslator dance in FillRectWithMask in that case.

tobytailor - was the use of DrawTargetRecording trying to solve something for the non-print via parent case, which would include non-e10s as well?

Flags: needinfo?(tschneider)
This is "firefox53 --- affected". Can you help move this bug forward? Maybe it is related to layout.
Flags: needinfo?(howareyou322)
From crash report, we were failed to allocate the draw target for DrawTargetRecording.
We should fix the crash fist by adding the nullptr checking in [1].

Vincent, please help on this.

|[C0][GFX1]: Failed to create similar cairo surface! Size: Size(1275,1650) Status: 10 format 0 (t=260484) 
Assignee: nobody → vliu
Flags: needinfo?(howareyou322)
This should have been fixed by my backout in bug 1347646, where I backed out bug 1311512.

It's already been approved for uplift to Beta.
Assignee: vliu → bobowencode
Closed: 5 years ago
Depends on: 1347646
Flags: needinfo?(tschneider)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.