New issue
Advanced search Search tips

Issue 643289 link

Starred by 1 user

Issue metadata

Status: Archived
Owner:
Closed: Sep 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug



Sign in to add a comment

mash: ash crashes on startup if powerd is not running

Project Member Reported by jamescook@chromium.org, Sep 1 2016

Issue description

PowerManagerClient calls OnGetScreenBrightnessPercent, which returns an error because powerd isn't there. In the error handler it checks chromeos::system::StatisticsProvider->IsRunningOnVm() to decide whether to log an error. In mash ash we're not initializing a chromeos::system::StatisticsProvider, which means that  hits a CHECK failure.

https://cs.chromium.org/chromium/src/chromeos/dbus/power_manager_client.cc?q=OnGetScreenBrightnessPercent&sq=package:chromium&l=458&dr=CSs

Dan, is it expected that chrome should run properly if powerd isn't running?  People sometimes shut it off to keep the display from turning off.

Regardless, it seems like we might need a statistics provider.

From kylechar:

I took the following steps to figure it out. I got the following stack trace as the first crash.

[29601:29601:0901/111424:2568336503:FATAL:statistics_provider.cc(252)] Check failed: load_statistics_started_. 
#0 0x7fd28e43aee6 <unknown>
#1 0x7fd28e45a49e <unknown>
#2 0x7fd28f163288 <unknown>
#3 0x7fd28f16401b <unknown>
#4 0x7fd28f162a32 <unknown>
#5 0x7fd28f1ac386 <unknown>
#6 0x7fd28f20df7e <unknown>
<truncated>

Not a super useful stack trace but thankful it was a CHECK that failed and it lists the pid. At the very start of stderr we log the pid of every process mash_runner starts.

[29591:29594:0901/111422:2566660381:INFO:child_process_host.cc(202)] Launched child process pid=29601, instance=ash, name=exe:chrome_mash, user_id=505C0EE9-3013-43C0-82B0-A84F50CF8D84

To get stack traces I just rsync'd over a chrome binary with symbols and reran chrome.

[31504:31504:0901/112232:3056138078:FATAL:statistics_provider.cc(252)] Check failed: load_statistics_started_. 
#0 0x7f03dcfeaee6 base::debug::StackTrace::StackTrace()
#1 0x7f03dd00a49e logging::LogMessage::~LogMessage()
#2 0x7f03ddd13288 chromeos::system::StatisticsProviderImpl::WaitForStatisticsLoaded()
#3 0x7f03ddd1401b chromeos::system::StatisticsProviderImpl::GetMachineStatistic()
#4 0x7f03ddd12a32 chromeos::system::StatisticsProviderImpl::IsRunningOnVm()
#5 0x7f03ddd5c386 chromeos::PowerManagerClientImpl::OnGetScreenBrightnessPercent()
#6 0x7f03dddbdf7e dbus::ObjectProxy::OnCallMethodError()
#7 0x7f03dddbb784 _ZN4base8internal7InvokerINS0_9BindStateIMN4dbus11ObjectProxyEFvRKSsS6_NS_8CallbackIFvPNS3_8ResponseEELNS0_8CopyModeE1EEEPNS3_13ErrorResponseEEJ13scoped_refptrIS4_ESsSsSC_EEEFvSE_EE3RunEPNS0_13BindStateBaseEOSE_
#8 0x7f03dddbc438 dbus::ObjectProxy::RunResponseCallback()
<truncated>

PowerManagerClientImpl::OnGetScreenBrightnessPercent() talks to dbus so that seemed like the failure. I didn't have time to investigate it further.

 

Comment 1 by derat@chromium.org, Sep 1 2016

I don't want Chrome to crash unless the user's data is at risk otherwise, so no, this isn't expected. :-)

powerd is expected (by Chrome) to be running on a Chrome OS device. It does important things besides turning the screen off (e.g. it's part of the shutdown path). I've documented supported ways to override its behavior at https://www.chromium.org/chromium-os/packages/power_manager in the hopes that people quit stopping its upstart job. :-P

The code to avoid logging an error from OnGetScreenBrightnesPercent was added recently to handle the case where we're running on a VM that doesn't have a backlight (not when powerd isn't running). I think that it probably makes sense to initialize chromeos::StatisticsProvider in ash, since you'd probably want this code to behave similarly there. Do you just need a call to StatisticsProviderImpl::StartLoadingMachineStatistics()?
Yeah. The tricky bit is that we don't have or want content dependencies in ash/mus right now, and there's only a single thread in ash, but StatisticsProviderImpl wants to run on the FILE thread.

I'll take a look at how we could spin up something like a blocking pool. If that seems hard, I'll just reuse FakeStatisticsProvider in ash to keep people moving.

Comment 3 by derat@chromium.org, Sep 1 2016

You should feel free to ifdef out that check for ash/mus for now, too.
Status: Started (was: Assigned)
It turns out that StatisticsProviderImpl launches a tool binary (crossystem) to gather machine information. That's why in runs on the file thread. We don't want to launch that binary twice (once from chrome, once from ash).

So I'm going to wire up FakeStatisticsProvider for now, then later we'll need to sort out some chrome/mash communication to get the data ash needs.

Status: Fixed (was: Started)
Fixed with the commit below. For some reason bugdroid didn't update this bug.

commit fb20f602654bb390e495835aa5087f98d88143a5
Author: jamescook <jamescook@chromium.org>
Date:   Thu Sep 1 15:34:15 2016 -0700

    mash: Provide a fake chromeos StatisticsProvider in ash
    
    Lower-level code in //chromeos (like the power manager client) assumes it can
    use chromeos::system::StatisticsProvider to determine if it is running in a VM
    (among other things). This is causing CHECK failures on mash when powerd isn't
    running.
    
    For now, provide a fake implementation, since we don't want to create a
    StatisticsProviderImpl in both chrome and ash, as it runs an external binary
    to get its information, and we don't want to do that twice.
    
    BUG= 643289 
    TEST=manual, stop powerd, start chrome on device with --mash, no CHECK failure
    
    Review-Url: https://codereview.chromium.org/2297193007
    Cr-Commit-Position: refs/heads/master@{#416088}

Comment 6 by dchan@chromium.org, Oct 7 2016

Labels: VerifyIn-55

Comment 7 by dchan@google.com, Nov 19 2016

Labels: VerifyIn-56

Comment 8 by dchan@google.com, Jan 21 2017

Labels: VerifyIn-57

Comment 9 by dchan@google.com, Mar 4 2017

Labels: VerifyIn-58

Comment 10 by dchan@google.com, Apr 17 2017

Labels: VerifyIn-59

Comment 11 by dchan@google.com, May 30 2017

Labels: VerifyIn-60
Labels: VerifyIn-61

Comment 13 by dchan@chromium.org, Oct 14 2017

Status: Archived (was: Fixed)
Components: -MUS Internals>Services>WindowService

Sign in to add a comment