Chromebox crashes with dual screens |
|||
Issue descriptionChrome Version: 57.0.2987.32 -and- Dev channel 57.0.2987.19 OS: Chrome Issue description: Chromebox crashes with dual screens Device/Peripheral info: Device 1: Version: Dev channel 57.0.2987.32 PC: ASUS ChromeBox CN60 Monitor: 2x AOC 230LM00025 Devices: keyboard: Logitech keyboard k120 mouse dell with cable. (customer doesn't know the exact model) Device 2: Version: Dev channel 57.0.2987.19 PC: ASUS ChromeBox CN60 Monitor: 2x BENQ Senseye 3 Devices: keyboard: logitech deluxe 250 mouse: logitech rx 250 New crash IDs 2bf81c1880000000 c1898fe880000000 What steps will reproduce the problem? (1) Connect cfm unit to dual screen (2) experience crash What is the expected result? stability What happens instead? crash PII Protected Logs from both units: https://drive.google.com/drive/folders/0B6fESMmJITTNQV9aTzllTEFCVEE?usp=sharing Errors found in logs: log/ui/ui.20170201-100202:[1:556:0202/153728.946837:ERROR:render_media_log.cc(30)] MediaEvent: MEDIA_ERROR_LOG_ENTRY {"error":"FFmpegDemuxer: failed creating video stream"} -and- log/messages.6:2017-02-01T11:15:15.017476+01:00 ERR kernel: [ 4390.486719] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 86
,
Feb 10 2017
Not able to reproduce this issue on build 9202.18.0/57.0.2987.32 Tested Device: Panther Monitors : ASUS VE, HP Z27n and LG (monroe)
,
Mar 22 2017
The crashes are both: 0x00007fc93028446f (libpthread-2.23.so + 0x0000d46f ) pthread_cond_wait 0x00007fc933d9690f (chrome -waiter.cc:64 ) mojo::edk::Waiter::Wait(unsigned long, unsigned long*) 0x00007fc9316abece (chrome -core.cc:1166 ) mojo::edk::Core::WaitManyInternal(unsigned int const*, unsigned int const*, unsigned int, unsigned long, unsigned int*, mojo::edk::HandleSignalsState*) 0x00007fc933d88a12 (chrome -core.cc:414 ) mojo::edk::Core::Wait(unsigned int, unsigned int, unsigned long, MojoHandleSignalsState*) 0x00007fc932fd2b42 (chrome -handle.h:191 ) mojo::SyncHandleRegistry::WatchAllHandles(bool const**, unsigned long) 0x00007fc933932652 (chrome -ipc_sync_channel.cc:619 ) IPC::SyncChannel::WaitForReply(mojo::SyncHandleRegistry*, IPC::SyncChannel::SyncContext*, bool) 0x00007fc93167883f (chrome -ipc_sync_channel.cc:583 ) IPC::SyncChannel::Send(IPC::Message*) 0x00007fc931a36aed (chrome -command_buffer_proxy_impl.cc:739 ) gpu::CommandBufferProxyImpl::Send(IPC::Message*) 0x00007fc931a374c5 (chrome -command_buffer_proxy_impl.cc:389 ) gpu::CommandBufferProxyImpl::WaitForGetOffsetInRange(int, int) 0x00007fc931a2db3e (chrome -cmd_buffer_helper.cc:168 ) gpu::CommandBufferHelper::WaitForGetOffsetInRange(int, int) 0x00007fc931a2dcce (chrome -cmd_buffer_helper.cc:223 ) gpu::CommandBufferHelper::Finish() 0x00007fc933ca1634 (chrome -gles2_implementation.cc:477 ) gpu::gles2::GLES2Implementation::WaitForCmd() 0x00007fc933ca48d0 (chrome -gles2_implementation.cc:361 ) gpu::gles2::GLES2Implementation::FreeEverything() 0x00007fc933c9da5b (chrome -gles2_implementation.cc:434 ) gpu::gles2::GLES2Implementation::SetAggressivelyFreeResources(bool) piman@ does this ring any bells to you/ideas where to send it? Idk why it'd show a crash on a pthread_cond_wait, it doesn't report as a hang or anything and this is in the browser process.
,
Mar 22 2017
It's a browser hang, with the session manager killing it with SIGABRT. You can tell by looking at the chrome.txt file attached to the bug. This is a dup of 661306 |
|||
►
Sign in to add a comment |
|||
Comment 1 by yye...@google.com
, Feb 10 2017