New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 631316 link

Starred by 1 user
Status: Duplicate
Merged: issue 538697
Owner: ----
Closed: Jul 2016
Cc:
█ kbr@chromium.org
mpear...@chromium.org
zmo@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

printing/webgl-oversized-printing.html crashes

Project Member Reported by zmo@chromium.org, Jul 26 2016 
See https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win7%20%28dbg%29/builds/6624

printing/webgl-oversized-printing.html
virtual/threaded/printing/webgl-oversized-printing.html

19:44:09.983 888   Backtrace:
19:44:09.983 888   	RaiseException [0x76B9C42D+88]
19:44:09.984 888   	base::EnableTerminationOnOutOfMemory [0x01BDBBC4+68]
19:44:09.984 888   	callnewh [0x6D2B6EA6+54]
19:44:09.984 888   	toupper [0x6D2B3C78+120]
19:44:09.984 888   	malloc_dbg [0x6D2B642A+26]
19:44:09.984 888   	malloc [0x6D2B6D54+20]
19:44:09.984 888   	gl::ClearGLBindingsGL [0x0485D959+473]
19:44:09.984 888   	gl::GLApiBase::glRenderbufferStorageEXTFn [0x0481A305+37]
19:44:09.984 888   	gpu::gles2::GLES2DecoderImpl::DoRenderbufferStorage [0x021E078E+494]
19:44:09.984 888   	gpu::gles2::GLES2DecoderImpl::HandleRenderbufferStorage [0x02200A15+389]
19:44:09.984 888   	gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<0> [0x021B1659+697]
19:44:09.984 888   	gpu::gles2::GLES2DecoderImpl::DoCommands [0x021D4D99+73]
19:44:09.984 888   	gpu::CommandParser::ProcessCommands [0x0214B23F+111]
19:44:09.984 888   	gpu::CommandExecutor::PutChanged [0x0214E9C9+873]
19:44:09.984 888   	gpu::GpuCommandBufferStub::PutChanged [0x02424C9C+60]
19:44:09.984 888   	??$Invoke@PAVGpuCommandBufferStub@gpu@@$$V@?$FunctorTraits@P8GpuCommandBufferStub@gpu@@AEXXZX@internal@base@@SAXP8GpuCommandBufferStub@gpu@@AEXXZ$$QAPAV34@@Z [0x02419CC5+21]
19:44:09.984 888   	base::internal::InvokeHelper<0,void>::MakeItSo<void (__thiscall gpu::GpuCommandBufferStub::*const &)(void),gpu::GpuCommandBufferStub *> [0x0241A388+40]
19:44:09.984 888   	base::internal::Invoker<base::internal::BindState<void (__thiscall gpu::GpuCommandBufferStub::*)(void),base::internal::UnretainedWrapper<gpu::GpuCommandBufferStub> >,void __cdecl(void)>::RunImpl<void (__thiscall gpu::GpuCommandBufferStub::*const &)(void), [0x0241A6CB+59]
19:44:09.984 888   	base::internal::Invoker<base::internal::BindState<void (__thiscall gpu::GpuCommandBufferStub::*)(void),base::internal::UnretainedWrapper<gpu::GpuCommandBufferStub> >,void __cdecl(void)>::Run [0x02425064+36]
19:44:09.984 888   	base::Callback<void __cdecl(void),1>::Run [0x0214C8BE+30]
19:44:09.984 888   	gpu::CommandBufferService::Flush [0x0214C5AB+75]
19:44:09.984 888   	gpu::GpuCommandBufferStub::OnAsyncFlush [0x024211AD+605]
19:44:09.984 888   	??$DispatchToMethodImpl@PAVGpuCommandBufferStub@gpu@@P812@AEXHIABV?$vector@VLatencyInfo@ui@@V?$allocator@VLatencyInfo@ui@@@std@@@std@@@ZHIV34@$$Z$0A@$00$01@base@@YAXABQAVGpuCommandBufferStub@gpu@@P812@AEXHIABV?$vector@VLatencyInfo@ui@@V?$allocator@VLatenc [0x02419A14+84]
19:44:09.984 888   	base::DispatchToMethod<gpu::GpuCommandBufferStub *,void (__thiscall gpu::GpuCommandBufferStub::*)(int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::LatencyInfo> > const &),int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::Laten [0x0241953E+30]
19:44:09.984 888   	IPC::DispatchToMethod<gpu::GpuCommandBufferStub,void (__thiscall gpu::GpuCommandBufferStub::*)(int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::LatencyInfo> > const &),void,std::tuple<int,unsigned int,std::vector<ui::LatencyInfo,std::alloca [0x02419768+24]
19:44:09.984 888   	IPC::MessageT<GpuCommandBufferMsg_AsyncFlush_Meta,std::tuple<int,unsigned int,std::vector<ui::LatencyInfo,std::allocator<ui::LatencyInfo> > >,void>::Dispatch<gpu::GpuCommandBufferStub,gpu::GpuCommandBufferStub,void,void (__thiscall gpu::GpuCommandBufferSt [0x02418775+213]
19:44:09.984 888   	gpu::GpuCommandBufferStub::OnMessageReceived [0x02422696+1158]
19:44:09.984 888   	IPC::MessageRouter::RouteMessage [0x0188C89A+58]
19:44:09.984 888   	gpu::GpuChannel::HandleMessageHelper [0x023FA028+72]
19:44:09.984 888   	gpu::GpuChannel::HandleMessage [0x023F9E0B+459]
19:44:09.984 888   	base::internal::FunctorTraits<void (__thiscall gpu::GpuChannel::*)(scoped_refptr<gpu::GpuChannelMessageQueue> const &),void>::Invoke<base::WeakPtr<gpu::GpuChannel> const &,scoped_refptr<gpu::GpuChannelMessageQueue> const &> [0x023E9685+37]
19:44:09.984 888   	base::internal::InvokeHelper<1,void>::MakeItSo<void (__thiscall gpu::GpuChannel::*const &)(scoped_refptr<gpu::GpuChannelMessageQueue> const &),base::WeakPtr<gpu::GpuChannel> const &,scoped_refptr<gpu::GpuChannelMessageQueue> const &> [0x023E9DC6+70]
19:44:09.985 888   	base::internal::Invoker<base::internal::BindState<void (__thiscall gpu::GpuChannel::*)(scoped_refptr<gpu::GpuChannelMessageQueue> const &),base::WeakPtr<gpu::GpuChannel>,scoped_refptr<gpu::GpuChannelMessageQueue> >,void __cdecl(void)>::RunImpl<void (__thi [0x023E9F63+83]
19:44:09.985 888   	base::internal::Invoker<base::internal::BindState<void (__thiscall gpu::GpuChannel::*)(scoped_refptr<gpu::GpuChannelMessageQueue> const &),base::WeakPtr<gpu::GpuChannel>,scoped_refptr<gpu::GpuChannelMessageQueue> >,void __cdecl(void)>::Run [0x023FDCB4+36]
19:44:09.985 888   	base::Callback<void __cdecl(void),1>::Run [0x01AAD0CE+30]
19:44:09.985 888   	base::debug::TaskAnnotator::RunTask [0x01ADBB64+324]
19:44:09.985 888   	base::MessageLoop::RunTask [0x01B4C7B0+640]
19:44:09.985 888   	base::MessageLoop::DeferOrRunPendingTask [0x01B4A4AC+44]
19:44:09.985 888   	base::MessageLoop::DoWork [0x01B4AB32+242]
19:44:09.985 888   	base::MessagePumpForGpu::DoRunLoop [0x01B542D2+98]
19:44:09.985 888   	base::MessagePumpWin::Run [0x01B5610B+123]
19:44:09.985 888   	base::MessageLoop::RunHandler [0x01B4C4F1+193]
19:44:09.985 888   	base::RunLoop::Run [0x01BF1ED4+52]
19:44:09.985 888   	content::GpuMain [0x1034324B+2699]
19:44:09.985 888   	content::RunNamedProcessTypeMain [0x12B7D7E7+135]
19:44:09.985 888   	content::ContentMainRunnerImpl::Run [0x12B7D6A8+488]
19:44:09.985 888   	content::ContentMain [0x12B7B4E4+100]
19:44:09.985 888   	wWinMain [0x00446438+72]
19:44:09.985 888   	invoke_main [0x00E5853E+30] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:118)
19:44:09.985 888   	__scrt_common_main_seh [0x00E5840A+346] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255)
19:44:09.985 888   	__scrt_common_main [0x00E582AD+13] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:300)
19:44:09.985 888   	wWinMainCRTStartup [0x00E58548+8] (f:\dd\vctools\crt\vcstartup\src\startup\exe_wwinmain.cpp:17)
19:44:09.985 888   	BaseThreadInitThunk [0x7505337A+18]
19:44:09.985 888   	RtlInitializeExceptionChain [0x776292B2+99]
19:44:09.985 888   	RtlInitializeExceptionChain [0x77629285+54]
19:44:09.985 888   	invoke_main [0x00E5853F+31] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:118)
19:44:09.985 888   	(No symbol) [0xFFFDE000]

Comment 1 by zmo@chromium.org, Jul 26 2016 

https://codereview.chromium.org/2181193002/ was reverted in this failure because that CL touched WebGL.  However, that CL only affects WebGL2 and looking at the out-of-memory failure, I am 99% sure it's unrelated. Besides, these two tests have been flaky.

Relanding my CL.

Comment 2 by mpear...@chromium.org, Jul 26 2016

Labels: Sheriff-Chromium
Owner: zmo@chromium.org
Status: Assigned (was: Available)
zmo@, it sounds like you're familiar with webgl stuff.

Can you find a proper owner for this?

These crashes happen consistently starting with this build:
https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Win7%20%28dbg%29/builds/6624

Comment 3 by zmo@chromium.org, Jul 26 2016

Cc: -mpear...@chromium.org zmo@chromium.org
Owner: mpear...@chromium.org
I am on a conference now and won't be able to look at this until next week.

This is testing over-sized buffers, and the failure is out-of-mem, so likely there's nothing we can do here. The memory increase might be gradual through many CLs. Assume if one CL caused dramatic mem assumption increase, we have other mem usage perf tests to guard against that? In this case, I suggest to suppress these two tests for Win Dbg.

Comment 4 by mpear...@chromium.org, Jul 26 2016

Cc: mpear...@chromium.org
Owner: ----
Status: Untriaged (was: Assigned)
As I'm not longer sheriff, I get (read: need) a break from disabling things.  Marking as untriaged and putting it in the current sheriff queue so one of them can disable it.

Comment 5 by robliao@chromium.org, Jul 26 2016 

This test appears to have already been suppressed:
https://cs.chromium.org/chromium/src/third_party/WebKit/LayoutTests/TestExpectations?q=printing/webgl-oversized-printing.html&sq=package:chromium&l=50&dr=C

 crbug.com/538697  [ Win7 Debug ] printing/webgl-oversized-printing.html [ Crash ]

Any idea what's up?

Comment 6 by zmo@chromium.org, Jul 26 2016 

It might be the crash is in GPU process, whereas the harness only handles renderer processes. Maybe it should be marked as crash and fail.
Project Member

Comment 7 by bugdroid1@chromium.org, Jul 27 2016 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc4ea63f0139e70248eb7f524c720a181295edb5

commit fc4ea63f0139e70248eb7f524c720a181295edb5
Author: vabr <vabr@chromium.org>
Date: Wed Jul 27 07:54:23 2016

Mark webgl-oversized-printing.html as Failure

The test crashes and is already marked as Crash, but as
 http://crbug.com/631316#c6 , the test harness might not be recognising this kind
of crashes as crashes but failures.

TBR=zmo@chromium.org
BUG= 631316 , 538697 
NOTRY=true

Review-Url: https://codereview.chromium.org/2186843002
Cr-Commit-Position: refs/heads/master@{#408073}

[modify] https://crrev.com/fc4ea63f0139e70248eb7f524c720a181295edb5/third_party/WebKit/LayoutTests/TestExpectations

Comment 8 by vabr@chromium.org, Jul 27 2016

Mergedinto: 538697
Status: Duplicate (was: Untriaged)
►

Sign in to add a comment