Issue metadata
Sign in to add a comment
|
context_lost flake in DoBindTexture
Reported by
dyen@chromium.org,
May 18 2016
|
||||||||||||||||||||||||
Issue descriptionI'm seeing a context_lost flake happening pretty consistently starting yesterday (5/17). Here is the callstack: Backtrace: (No symbol) [0x00000000] (No symbol) [0x5B5034E1] gpu::gles2::GLES2DecoderImpl::DoBindTexture [0x5CCF431C+369] RtlFreeHeap [0x7794E023+126] HeapFree [0x753A14BD+20] free [0x5C3428C7+20] gpu::gles2::GLES2DecoderImpl::GenTexturesHelper [0x5CCFD3AE+152] gpu::gles2::GLES2DecoderImpl::HandleBindTexture [0x5CD001C4+89] gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<0> [0x5CCEC98E+197] gpu::CommandParser::ProcessCommands [0x5CCDB6FD+49] gpu::CommandExecutor::PutChanged [0x5CCDC2BB+484] gpu::CommandBufferService::Flush [0x5CCDBAB5+30] gpu::GpuCommandBufferStub::OnAsyncFlush [0x5CDE1C86+345] 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 [0x5CDDFEB9+142] gpu::GpuCommandBufferStub::OnMessageReceived [0x5CDE24C5+485] gpu::GpuChannel::HandleMessageHelper [0x5CDDBDA3+44] gpu::GpuChannel::HandleMessage [0x5CDDBCE4+346] base::internal::InvokeHelper<1,void,base::internal::RunnableAdapter<void (__thiscall content::WebMediaPlayerMS::*)(scoped_refptr<media::VideoFrame> const &)> >::MakeItSo<base::WeakPtr<content::WebMediaPlayerMS>,scoped_refptr<media::VideoFrame> const &> [0x5D1E5A3F+48] base::internal::Invoker<base::IndexSequence<0,1>,base::internal::BindState<base::internal::RunnableAdapter<void (__thiscall content::WebBluetoothServiceImpl::*)(mojo::Callback<void __cdecl(enum blink::mojom::WebBluetoothError)> const &)>,void __cdecl(cont [0x5CDDDACD+45] base::debug::TaskAnnotator::RunTask [0x5EFF1DD7+247] base::MessageLoop::RunTask [0x5EF8011B+1211] base::MessageLoop::DoWork [0x5EF7F1D5+549] base::MessagePumpForUI::DoRunLoop [0x5EFC4F7A+90] base::MessagePumpWin::Run [0x5EFC589A+74] base::MessageLoop::RunHandler [0x5EF7FC57+103] base::RunLoop::Run [0x5EFE9DB9+41] base::MessageLoop::Run [0x5EF7FBE2+98] content::GpuMain [0x5EBF719F+1768] content::RunNamedProcessTypeMain [0x5EF57FEF+176] content::ContentMainRunnerImpl::Run [0x5EF57F0E+274] content::ContentMain [0x5EF57324+35] ChromeMain [0x5C33AC8C+108] MainDllLoader::Launch [0x003DE9A1+488] wWinMain [0x003DD88E+450] __scrt_common_main_seh [0x00C5B605+253] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255) BaseThreadInitThunk [0x753A337A+18] RtlInitializeExceptionChain [0x779592B2+99] RtlInitializeExceptionChain [0x77959285+54] pre_cpp_initialization [0x00C5B4FD+17] (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:188) (No symbol) [0xFFFDE000]
,
May 18 2016
,
May 18 2016
David, could you check the logs under src/ui/gl and src/gpu and see if there's anything suspicious that changed?
,
May 18 2016
Nothing has really been changed other than the RGB_565 support. Even that seems like it wouldn't cause something like this... adding reveman@ to see what he thinks.
,
May 19 2016
I looked into this yesterday but I couldn't reproduce it locally. Could you take a look reveman@? Your patch is the only one that looks remotely related since not a lot of GPU work has landed lately.
,
May 19 2016
The code in the RGB_565 related changes I landed recently shouldn't be used by chrome yet. It would surprise me if they someone cause a context lost.
,
May 19 2016
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dyen@chromium.org
, May 18 2016