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

Issue 766812 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

veyron_minnie informational chrome pfq failed HWTest with error "Android did not boot!"

Project Member Reported by x...@chromium.org, Sep 19 2017

Issue description

The build link: https://uberchromegw.corp.google.com/i/chromeos.chrome/builders/veyron_minnie-tot-chrome-pfq-informational/builds/6085

It started failing from 6085 build (see link above) with "cheets_SettingsBridge: FAIL: Android did not boot!" 

Not sure if it's a flaky issue yet. Will keep monitoring.

 
This looks like a chrome crash.  Here is the top stack frames and doesn't look like ARC related.  Do you see similar thing on other builder?

Thread 0 (crashed)
 0  chrome!net::NSSCertDatabase::NSSCertDatabase(std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >, std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >) [nss_cert_database.cc : 81 + 0x0]
     r0 = 0x00000000    r1 = 0x42b67450    r2 = 0x00000000    r3 = 0x00000000
     r4 = 0x42b67450    r5 = 0x42a3f690    r6 = 0x42b67420    r7 = 0x0000002c
     r8 = 0x3b63f8d1    r9 = 0x9ae65afc   r10 = 0x3ecbcada   r12 = 0x3a4040a5
     fp = 0x9ae65cf0    sp = 0x9ae65a68    lr = 0x3b9cd355    pc = 0x3b9cd396
    Found by: given as instruction pointer in context
 1  chrome!net::NSSCertDatabaseChromeOS::NSSCertDatabaseChromeOS(std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >, std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >) [nss_cert_database_chromeos.cc : 26 + 0x5]
     r4 = 0x42b67450    r5 = 0x00000000    r6 = 0x42b67450    r7 = 0x9ae65ab4
     r8 = 0x3b63f8d1    r9 = 0x9ae65afc   r10 = 0x3ecbcada    fp = 0x9ae65cf0
     sp = 0x9ae65a80    pc = 0x3b9ce577
    Found by: call frame info
 2  chrome!(anonymous namespace)::NSSCertDatabaseChromeOSManager::DidGetPrivateSlot(std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >) [nss_context_chromeos.cc : 57 + 0x5]
     r4 = 0x417df840    r5 = 0x9ae65ad8    r6 = 0x42b67450    r7 = 0x9ae65ab4
     r8 = 0x3b63f8d1    r9 = 0x9ae65afc   r10 = 0x3ecbcada    fp = 0x9ae65cf0
     sp = 0x9ae65ab0    pc = 0x3b63f909
    Found by: call frame info
 3  chrome!base::internal::Invoker<base::internal::BindState<void ((anonymous namespace)::NSSCertDatabaseChromeOSManager::*)(std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >), base::WeakPtr<(anonymous namespace)::NSSCertDatabaseChromeOSManager> >, void (std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >)>::Run(base::internal::BindStateBase*, std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >&&) [bind_internal.h : 194 + 0x1]
     r4 = 0x9ae65afc    r5 = 0x4171b920    r6 = 0x4171b938    r7 = 0x00000000
     r8 = 0x3b63f8d1    r9 = 0x9ae65afc   r10 = 0x3ecbcada    fp = 0x9ae65cf0
     sp = 0x9ae65ad8    pc = 0x3ad327b5
    Found by: call frame info
 4  chrome!crypto::(anonymous namespace)::ChromeOSUserData::SetPrivateSlot(std::unique_ptr<PK11SlotInfoStr, crypto::NSSDestroyer<PK11SlotInfoStr, &PK11_FreeSlot> >) [callback.h : 92 + 0x1]
     r4 = 0x00000000    r5 = 0x40806c40    r6 = 0x413cffd0    r7 = 0x413cffd4
     r8 = 0x413cffd0    r9 = 0x9ae65afc   r10 = 0x3ecbcada    fp = 0x9ae65cf0
     sp = 0x9ae65af8    pc = 0x3bb3e8df
    Found by: call frame info
 5  chrome!crypto::(anonymous namespace)::NSSInitSingleton::OnInitializedTPMForChromeOSUser(std::string const&, std::unique_ptr<crypto::(anonymous namespace)::NSSInitSingleton::TPMModuleAndSlot, std::default_delete<crypto::(anonymous namespace)::NSSInitSingleton::TPMModuleAndSlot> >) [nss_util.cc : 501 + 0x3]
     r4 = 0x9ae65b30    r5 = 0x42917558    r6 = 0x9ae65b40    r7 = 0x3f869790
     r8 = 0x3edd4d55    r9 = 0x4001e958   r10 = 0x3ecbcada    fp = 0x9ae65cf0
     sp = 0x9ae65b20    pc = 0x3bb3e7ad
    Found by: call frame info
 6  chrome!base::internal::Invoker<base::internal::BindState<void (crypto::(anonymous namespace)::NSSInitSingleton::*)(base::RepeatingCallback<void (bool)> const&, std::unique_ptr<crypto::(anonymous namespace)::NSSInitSingleton::TPMModuleAndSlot, std::default_delete<crypto::(anonymous namespace)::NSSInitSingleton::TPMModuleAndSlot> >), base::internal::UnretainedWrapper<crypto::(anonymous namespace)::NSSInitSingleton>, base::RepeatingCallback<void (bool)>, base::internal::PassedWrapper<std::unique_ptr<crypto::(anonymous namespace)::NSSInitSingleton::TPMModuleAndSlot, std::default_delete<crypto::(anonymous namespace)::NSSInitSingleton::TPMModuleAndSlot> > > >, void ()>::RunOnce(base::internal::BindStateBase*) [bind_internal.h : 194 + 0x1]
     r4 = 0x00000000    r5 = 0x42917558    r6 = 0x9ae65b40    r7 = 0x3f869790
     r8 = 0x3edd4d55    r9 = 0x4001e958   r10 = 0x3ecbcada    fp = 0x9ae65cf0
     sp = 0x9ae65b30    pc = 0x3bb3e3ad
    Found by: call frame info
 7  chrome!base::(anonymous namespace)::PostTaskAndReplyRelay::RunReplyAndSelfDestruct() [callback.h : 64 + 0x1]
     r4 = 0x42917540    r5 = 0x42917558    r6 = 0x9ae65b40    r7 = 0x3f869790
     r8 = 0x3edd4d55    r9 = 0x4001e958   r10 = 0x3ecbcada    fp = 0x9ae65cf0
     sp = 0x9ae65b40    pc = 0x3b80bd11
    Found by: call frame info

Comment 2 by x...@chromium.org, Sep 19 2017

Until now veyron_minnie is the only informational builder that failed with this error. 

Comment 3 by kinaba@chromium.org, Sep 20 2017

Cc: kinaba@chromium.org
Let me add a note on why the crash is surfaced as "Android did not boot!".

The direct cause that Android did not boot is in the chrome log:
[12340:12340:0919/131253.945699:VERBOSE1:arc_util.cc(263)] Users with SDK version (25) are not supported when they postponed to migrate to dircrypto.
This means, ARC conservatively thought that the user data filesystem was too old to host Android N.
(I'm commenting because I am the person who added the check.)

Actually the filesystem is ok. The root problem is indeed the Chrome crash that Victor mentioned.

The browser process is crashing (1) soon after the sign-in, (2) but before dumping the results of filesystem check to the local state.
Session manager restarts the Chrome process without re-requesting the sign-in, and in this fast-restart code path, the filesystem check is skipped (assuming it stored in the local state; which is true except for the sign-in-crash cases exactly like this.)

Comment 4 by x...@chromium.org, Sep 20 2017

Status: WontFix (was: Untriaged)
The build cycled green again. I didn't observe the same failure anymore. So I think it's just flakiness. Close it.

Sign in to add a comment