If I understand how crashes work for Chrome, the CrOS crash handler lets Chrome handle the crash so a fix will involve modifying the crash recovery logic in Chrome for ChromeOS.

Feel free to reassign as needed.

Even if Chrome is handling the crash does that mean it can override OS settings  like "Sleep when lid is closed" or should that still take effect.

The tricky thing with the lid is Chrome may be in the process of handling a crash when the lid close event would normally be processed. If Chrome is supposed to handle that event, the event would be dropped, so either the Chrome crash recovery logic on Chrome OS needs to check the state of the device and handle this scenario correctly or the service that delivers the event would need to know if the event wasn't processed (probably session-manager) and repeat the event after Chrome recovered.

+derat for power settings
+rkc for lock screen

Any chance to get a feedback report taken shortly after the observed event?

Please see the docs at https://chromium.googlesource.com/chromiumos/platform2/+/master/login_manager/#screen-locking and https://chromium.googlesource.com/chromiumos/platform2/+/master/login_manager/#crashes. If Chrome crashes while the screen is locked, the session should be ended automatically. If Chrome crashes before it tells session_manager to lock the screen, then that logic won't take effect, though.

Scott, were you logged in with a google.com account when this happened? You're seeing the screen normally get locked when you suspend the system and wake it up later, right?

We'll probably need a feedback report submitted soon after this occurs to investigate further.

Likely a duplicate of  issue 867970 ; I'm going to ping mnissler@ to get feedback on potential solutions discussed there.

#7 Yes, I did file feedback on May 4th (HP Chromebook) and again on Aug 14 (Google Pixelbook) but did not see any activity on those. It has happened a few times other than those two incidents. What is the best way to get you those feedback links?   Okay to post here?

#8 I was logged in with a google.com account. And everything resumed and worked fine after that (e.g. it would lock if I closed the lid again).

#10: Ah, thanks. Feedback reports are here:

http://feedback/#/Report/78236256670
http://feedback/#/Report/85398547232
http://feedback/#/Report/85601740548

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Awesome glad you found those. Note the first one (78236256670) was a slightly different issue where the OS was just in a strange pseudo locked, pseudo unlocked state not caused by a "restore all tabs" kind of crash. 

Hmm, 85398547232 doesn't have logs attached to it. Maybe the system info checkbox in the feedback dialog got unchecked?

85601740548 has logs, though. The lid was closed at 17:21:25, but the system didn't suspend immediately since it was in docked mode:

[0813/172125:INFO:daemon.cc(514)] Lid closed
[0813/172125:INFO:input_device_controller.cc(284)] Configuring devices for mode "docked"
...
[0813/172126:INFO:state_controller.cc(1025)] Ready to perform lid-closed action (no-op)

It was a few weeks ago, but do you recall if you had an external display connected or were casting or screen-sharing or something similar? The device looks like it was still in use at that point:

[0813/184551:INFO:activity_logger.cc(20)] Audio activity ongoing
[0813/184552:INFO:activity_logger.cc(20)] User activity reported
...
[0813/184623:INFO:activity_logger.cc(20)] Video activity reported

It looks like Chrome reported that the extra display went away a bit later, resulting in the system suspending immediately:

[0813/191232:INFO:daemon.cc(1332)] Chrome is using normal display mode
[0813/191232:INFO:state_controller.cc(876)] Updated settings: dim=10m screen_off=10m30s lock=10m40s idle_warn=0s idle=11m30s (suspend) lid_closed=suspend use_audio=1 use_video=1 wake_locks=
[0813/191232:INFO:state_controller.cc(978)] Turning panel on after leaving docked mode
[0813/191232:INFO:display_power_setter.cc(81)] Asking DisplayService to turn all displays on
[0813/191233:ERROR:object_proxy.cc(582)] Failed to call method: org.chromium.DisplayServiceInterface.SetPower: object_path= /org/chromium/DisplayService: org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying
[0813/191233:INFO:internal_backlight_controller.cc(688)] Setting brightness to 49330 (87.5%) over 0 ms
[0813/191233:INFO:keyboard_backlight_controller.cc(537)] Setting brightness to 60 (60%) over 0 ms
[0813/191233:INFO:state_controller.cc(1025)] Ready to perform lid-closed action (suspend)

But yeah, I think that Chrome crashed around then:

[0813/191234:INFO:daemon.cc(1332)] Chrome is using normal display mode
[0813/191234:INFO:suspend_delay_controller.cc(121)] Unregistering suspend delay 81264642 (chrome) due to D-Bus client :1.10 going away
[0813/191234:INFO:suspend_delay_controller.cc(121)] Unregistering dark suspend delay 81297410 (chrome) due to D-Bus client :1.10 going away

The system resumed the next morning, and Chrome finished starting up then:

[0814/094346:INFO:suspender.cc(408)] Finishing request 81264663 successfully
[0814/094346:INFO:internal_backlight_controller.cc(688)] Setting brightness to 49330 (87.5%) over 0 ms
[0814/094346:INFO:keyboard_backlight_controller.cc(537)] Setting brightness to 60 (60%) over 200 ms
[0814/094346:INFO:daemon.cc(523)] Lid opened
...
[0814/094347:INFO:suspend_delay_controller.cc(62)] Registering suspend delay 81264645 (chrome) of 5000 ms on behalf of :1.260
[0814/094347:INFO:suspend_delay_controller.cc(62)] Registering dark suspend delay 81297411 (chrome) of 5000 ms on behalf of :1.260
[0814/094347:INFO:daemon.cc(788)] D-Bus org.chromium.DisplayService ownership changed to :1.260

Here's session_manager seeing Chrome die (with SIGILL):

2018-08-13T19:12:33.497932-07:00 INFO session_manager[1267]: [INFO:child_exit_handler.cc(77)] Handling 1302 exit.
2018-08-13T19:12:33.497948-07:00 ERR session_manager[1267]: [ERROR:child_exit_handler.cc(85)]   Exited with signal 4
2018-08-13T19:12:33.497959-07:00 INFO session_manager[1267]: [INFO:session_manager_service.cc(296)] Exiting process is chrome.

I suspected that Chrome died while the system was in docked mode, resulting in the system suspending immediately and the newly-restarted Chrome process failing to lock the screen. The mitigations discussed in  issue 867970  would have helped here.

Yes. I had an external monitor and power connected. 

More info: This is pretty common for me: (1) Have Chromebook plugged into power + external monitor + keyboard/mouse with lid closed.  (2) I pull the plug on the monitor, power, etc. then take laptop and walk away. I do this probably 20-30 times per week and have seen this error ~1-2 times per month. 

I think that crash/a1339a9b73957e70 is the Chrome crash that triggered this. It's code that runs when displays are reconfigured, so it lines up with being triggered when you unplug the external monitor.

Thread 0 (id: 0x516) CRASHED [SIGTRAP @ 0x00000000 ]
0x00005bca48ce7a50	(chrome -window_tree_host_manager.cc:265 )	ash::ScreenAsh::GetDisplayMatching(gfx::Rect const&) const
0x00005bca48180aae	(chrome -native_widget_aura.cc:478 )	views::NativeWidgetAura::SetBounds(gfx::Rect const&)
0x00005bca48c0a9d7	(chrome -widget.cc:516 )	ash::ShelfLayoutManager::UpdateBoundsAndOpacity(ash::ShelfLayoutManager::TargetBounds const&, bool, bool, ui::ImplicitAnimationObserver*)
0x00005bca48c0b3d2	(chrome -shelf_layout_manager.cc:612 )	ash::ShelfLayoutManager::SetState(ash::ShelfVisibilityState)
0x00005bca48ccc85c	(chrome -shelf.cc:183 )	<name omitted>
0x00005bca47d1a391	(chrome -window.cc:302 )	aura::Window::SetBounds(gfx::Rect const&)
0x00005bca48c9e29c	(chrome -window_selector_item.cc:1330 )	ash::WindowSelectorItem::UpdateHeaderLayout(ash::WindowSelectorItem::HeaderFadeInMode, ash::OverviewAnimationType)
0x00005bca48d772e1	(chrome -window_selector_item.cc:721 )	ash::WindowSelector::Shutdown()
0x00005bca48c9b7b7	(chrome -window_selector_controller.cc:415 )	ash::WindowSelectorController::OnSelectionEnded()
0x00005bca485c93f0	(chrome -display_manager.cc:2143 )	display::DisplayManager::UpdateDisplaysWith(std::__1::vector<display::ManagedDisplayInfo, std::__1::allocator<display::ManagedDisplayInfo> > const&)
0x00005bca485c3cf8	(chrome -display_manager.cc:889 )	display::DisplayManager::OnNativeDisplaysChanged(std::__1::vector<display::ManagedDisplayInfo, std::__1::allocator<display::ManagedDisplayInfo> > const&)
0x00005bca485b0fff	(chrome -display_change_observer.cc:207 )	display::DisplayChangeObserver::OnDisplayModeChanged(std::__1::vector<display::DisplaySnapshot*, std::__1::allocator<display::DisplaySnapshot*> > const&)
0x00005bca485b7b71	(chrome -display_configurator.cc:1167 )	display::DisplayConfigurator::NotifyDisplayStateObservers(bool, display::MultipleDisplayState)
0x00005bca485b59a6	(chrome -display_configurator.cc:1103 )	display::DisplayConfigurator::OnConfigured(bool, std::__1::vector<display::DisplaySnapshot*, std::__1::allocator<display::DisplaySnapshot*> > const&, display::MultipleDisplayState, chromeos::DisplayPowerState)
0x00005bca485c12b3	(chrome -callback.h:124 )	display::UpdateDisplayConfigurationTask::OnStateEntered(display::ConfigureDisplaysTask::Status)
0x00005bca485dea6e	(chrome -callback.h:124 )	display::ConfigureDisplaysTask::Run()
0x00005bca485dee52	(chrome -configure_displays_task.cc )	display::ConfigureDisplaysTask::OnConfigured(unsigned long, bool)
0x00005bca44726f8b	(chrome -callback.h:95 )	base::internal::Invoker<base::internal::BindState<base::OnceCallback<void (bool)>, bool>, void ()>::RunOnce(base::internal::BindStateBase*)
0x00005bca441b9693	(chrome -callback.h:95 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x00005bca441bc64f	(chrome -incoming_task_queue.cc:124 )	base::MessageLoop::RunTask(base::PendingTask*)
0x00005bca441bd0c0	(chrome -message_loop.cc:364 )	base::MessageLoop::DoWork()
0x00005bca441bdc65	(chrome -message_pump_libevent.cc:210 )	base::MessagePumpLibevent::Run(base::MessagePump::Delegate*)
0x00005bca46496377	(chrome -run_loop.cc:130 )	ChromeBrowserMainParts::MainMessageLoopRun(int*)
0x00005bca44cdcb80	(chrome -browser_main_loop.cc:989 )	content::BrowserMainLoop::RunMainMessageLoopParts()
0x00005bca44cdf9f1	(chrome -browser_main_runner.cc:161 )	content::BrowserMainRunnerImpl::Run()
0x00005bca44cd562d	(chrome -browser_main.cc:46 )	content::BrowserMain(content::MainFunctionParams const&)
0x00005bca4647bc23	(chrome -content_main_runner.cc:633 )	content::ContentMainRunnerImpl::Run()
0x00005bca4648715d	(chrome -main.cc:452 )	service_manager::Main(service_manager::MainParams const&)
0x00005bca442bf458	(chrome -content_main.cc:19 )	ChromeMain

Let's use this bug to track that crash and keep  issue 867970  for discussing the generic crash-while-suspending mitigation.

I think that this might be a duplicate of issue 866714, although the stack is different. Ahmed?

Yes, the crash in #17 is the same root cause as in issue 866714.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot