My crashes on the same version on Chell:

crash/1d72048cb25f98c9
crash/5e087d63c02b581f
crash/fefdfb70f6c84557

Feedback reports (with logs):
- Caroline: https://listnr.corp.google.com/report/85547682115
- Eve: https://listnr.corp.google.com/report/85547571907
- Eve: https://listnr.corp.google.com/report/85546484544
- Eve: https://listnr.corp.google.com/report/85546475001

From Googler's report - https://listnr.corp.google.com/report/85547696750

"Additional info on bootloop affecting 69.0.3486.0.

If you're able to login, subsequent logout will put you pack into the bad state."

i don't *think* memd is causing this, but there are a ton of crashes caused by it here.  those are already fixed in 10867.0.0 via  issue 860034 , but unfortunately 10866.1.0 was pushed to dev.

Hmm. I tried to look for Chrome crashes from the same ClientID as the crashes in #1, but I don't see anything newer than 69.0.3473.0: http://crash/browse?q=ClientID%3D%27d8640b24c17b4f48bf813cb3c5e59531%27+AND+product_name%3D%27Chrome_ChromeOS%27

The ones that I looked at from 69.0.3473.0 all look like they're in V8.

derat@, I've managed to login successfully and I have a fresh batch of crashes:

8f8b235d85c1ad2d
fe3ede4e9f5823bd
00a92313b9d40c8a
58205936da063436
a9998a95c1b89ddf

#11: Most of those are memd, so possibly just noise. crash/a9998a95c1b89ddf is a session_manager segfault that I haven't seen before.

From #3, http://listnr/product/208/report/85547571907 is from Todd but has an empty client ID (whyyyyyy?), so no way to look at crashes there. Sigh, and no client ID on http://listnr/product/208/report/85547682115 either, so probably something's broken in feedback reporting and/or Listnr too.

Does file:///var/log/messages suggest that Chrome (or some other process) is in a crash loop?

Adding others for their input.

The syslog file in 85547571907 confirms that Chrome is in a segfault loop:

2018-07-13T09:05:47.574443-07:00 INFO session_manager[1298]: [INFO:session_manager_service.cc(297)] Exiting process is chrome.
2018-07-13T09:05:51.393721-07:00 ERR session_manager[1298]: [ERROR:child_exit_dispatcher.cc(67)]   Exited with signal 11
2018-07-13T09:05:51.393735-07:00 INFO session_manager[1298]: [INFO:session_manager_service.cc(297)] Exiting process is chrome.
2018-07-13T09:05:57.004243-07:00 ERR session_manager[1298]: [ERROR:child_exit_dispatcher.cc(67)]   Exited with signal 11
2018-07-13T09:05:57.004269-07:00 INFO session_manager[1298]: [INFO:session_manager_service.cc(297)] Exiting process is chrome.
2018-07-13T09:06:02.492520-07:00 ERR session_manager[1298]: [ERROR:child_exit_dispatcher.cc(67)]   Exited with signal 11
2018-07-13T09:06:02.492561-07:00 INFO session_manager[1298]: [INFO:session_manager_service.cc(297)] Exiting process is chrome.
2018-07-13T09:06:08.203560-07:00 ERR session_manager[4264]: [ERROR:child_exit_dispatcher.cc(67)]   Exited with signal 11
2018-07-13T09:06:08.203583-07:00 INFO session_manager[4264]: [INFO:session_manager_service.cc(297)] Exiting process is chrome.
2018-07-13T09:06:13.550580-07:00 ERR session_manager[4264]: [ERROR:child_exit_dispatcher.cc(67)]   Exited with signal 11
2018-07-13T09:06:13.550596-07:00 INFO session_manager[4264]: [INFO:session_manager_service.cc(297)] Exiting process is chrome.

And sigh:

CLIENT_ID=<empty>

It's probably this?


https://crash.corp.google.com/browse?q=product_name%3D%27Chrome_ChromeOS%27+AND+product.Version%3D%2769.0.3486.0%27+AND+expanded_custom_data.ChromeCrashProto.ptype%3D%27browser%27+AND+expanded_custom_data.ChromeCrashProto.magic_signature_1.name%3D%27policy%3A%3AGetAllPolicyValuesAsDictionary%27

From /var/log/messages on Chell:

2018-07-13T10:35:53.210260-07:00 WARNING crash_reporter[2852]: Received crash notification for chrome[2734] user 1000 (called directly)
2018-07-13T10:35:53.211824-07:00 ERR crash_reporter[2852]: Could not get active user sessions, using default.
2018-07-13T10:35:53.211926-07:00 WARNING crash_reporter[2852]: Crash directory /home/chronos/crash already full with 32 pending reports
2018-07-13T10:35:53.211947-07:00 ERR crash_reporter[2852]: Can't create crash directory for uid 1000
2018-07-13T10:35:53.214768-07:00 INFO session_manager[990]: [INFO:child_exit_dispatcher.cc(59)] Handling 2852 exit.
2018-07-13T10:35:53.214951-07:00 ERR session_manager[990]: [ERROR:child_exit_dispatcher.cc(61)]   Exited with exit code 1
2018-07-13T10:35:53.215463-07:00 INFO kernel: [   16.519290] chrome[2734]: segfault at 8 ip 00006288ce15405c sp 00007ffe91d4e7c0 error 4 in chrome[6288cb7b9000+96d1000]
2018-07-13T10:35:53.221827-07:00 INFO crash_reporter[2853]: libminijail[2853]: mount /dev/log -> /dev/log type ''
2018-07-13T10:35:53.223462-07:00 DEBUG kernel: [   16.527795] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
2018-07-13T10:35:53.230459-07:00 DEBUG kernel: [   16.534357] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
2018-07-13T10:35:53.240158-07:00 WARNING crash_reporter[2853]: [user] Received crash notification for chrome[2734] sig 11, user 1000 (ignoring call by kernel - chrome crash; waiting for chrome to call us directly)
...
2018-07-13T11:56:50.493404-07:00 ERR crash_reporter[5320]: Could not get active user sessions, using default.
2018-07-13T11:56:50.494121-07:00 WARNING crash_reporter[5320]: Crash directory /home/chronos/crash already full with 32 pending reports
2018-07-13T11:56:50.494144-07:00 ERR crash_reporter[5320]: Can't create crash directory for uid 1000
2018-07-13T11:56:50.496052-07:00 NOTICE kernel: [   40.700092] audit: type=1400 audit(1531508210.495:14): avc:  denied  { module_request } for  pid=5334 comm="init" kmod="personality-8" scontext=u:r:init:s0 tcontext=u:r:kernel:s0 tclass=system permissive=0
2018-07-13T11:56:50.500047-07:00 DEBUG kernel: [   40.704537] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
2018-07-13T11:56:50.507091-07:00 DEBUG kernel: [   40.710790] SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs
2018-07-13T11:56:50.528054-07:00 INFO kernel: [   40.731929] chrome[5164]: segfault at 8 ip 0000600d5d46305c sp 00007ffcc4cb10a0 error 4 in chrome[600d5aac8000+96d1000]

feedback/CLIENT_ID shows as "<empty>" when i create debug logs from net-internals.

With eve board recovery to 10863.0.0 and AU to 10866.1.0 (or direct recovery to 10866.1.0) the issue can not be reproduced.

Every (re)boot generates three crashes
localhost / # ls /var/spool/crash/
memd.20180713.135951.2684.dmp   service_failure.20180713.135951.0.log   trunksd.20180713.135948.2005.dmp
memd.20180713.135951.2684.meta  service_failure.20180713.135951.0.meta  trunksd.20180713.135948.2005.meta

Uploaded as:
Crash Report ID 44f22139c7bb876c (Local Crash ID: ChromeOS)
Crash Report ID f58cfa9a0d99eb39 (Local Crash ID: ChromeOS)
Crash Report ID df2ff641d80a6102 (Local Crash ID: ChromeOS)

Rebooted 15 times, and reached the daily crash files limit. Still, I am able to successfully login.

I'm not able to reproduce, but given this happens in both webui and views login, and there is a crash spike, I suspect policy::GetAllPolicyValuesAsDictionary is the cause.

Related  issue 863075 .

It can also be related to  issue 860741 , as they share same code path.

The regression seems to be introduced by http://crrev.com/c/1108922, and changes in  issue 860741  seems to fix that.

Severity of this issue seems to be caused by fact that devices attempt to make a log snapshot right after reboot (requested by policy). We should probably add a safeguard for not attempting to upload logs too often, to prevent such reboot loops in a future.

Thanks for the updates antrim@

What's the plan for isolating this issue and submitting a CL to resolve?  Do you think it should be fixed per the crbug/860741 fix?  Has that been verified?

Trying to unblock for an already delayed DEV release.  Thanks. 

Also, please note crbug/861995 which is also related.  Which of these three is the root cause? Can we update those dependencies?

memd has already been disabled in the dev channel so it can't cause further issues

Re #24: The issue itself should be gone now in 69.0.3488.0 (zmin@ have confirmed it in  issue 863075  that is a duplicate of this one). I have a CL in review that would add extra guard checks so that log generation would not crash if similar situation arises in future, it would be landed under  issue 863075 . 

We don't have a dedicated issue that would address the way SystemLogUploader works (it does not store last upload attempt in any persistent location, so it would attempt uploading logs right after crash).

I am marking this issue as fixed for now.

I just got a request to update my OS today on my Eve and had a login screen boot loop: https://r1---sn-a5mekne7.googlevideo.com/videoplayback?id=d90ed7d05088c541&itag=18&source=picasa&begin=0&requiressl=yes&pl=16&sc=yes&ttl=transient&ei=t1aAW7jaOYPH-QPHg7C4Ag&susc=ph&app=fife&mime=video/mp4&lmt=1535136702918713&ip=73.140.252.104&ipbits=8&expire=1535144663&sparams=app,ei,expire,id,ip,ipbits,itag,lmt,mime,mm,mn,ms,mv,pl,requiressl,sc,source,susc,ttl&signature=6780A6AA98D6E1B020999DFA481777B87D3EF205.15C8514A0D8A698C1049D297BB39BC7E077C609F&key=cms1&redirect_counter=1&cm2rm=sn-nx5ee7l&fexp=23755740&req_id=42e4b7e1c98ea3ee&cms_redirect=yes&mm=34&mn=sn-a5mekne7&ms=ltu&mt=1535137355&mv=m

FWIW I did update a different Eve (PVT) also on beta channel and that went fine. But my released Eve went into that loop and I had to do  recovery to get it back.

I am reopening this. After recovering my Eve, I switched back to the Beta channel and got the same screen loop again. 

I don't have access to the video.

But canary/dev  is broken because https://chromium-review.googlesource.com/1184542 missed that branch.

RBB as we are in Beta now. Need escalation of resolution.

Assigning to alemate@ as he is the owner of mentioned CL.

I think we're tangling 3 different bugs here.
This bug tracks an issue with boot looping that was supposedly fixed in #27.
The CL alemate@ reverted fixes an issue with different symptoms.
This bug was reopened for the behavior in #30, which we have no evidence is the same root cause as the original issue here.

I've opened  bug 878002  to track ongoing investigation and to separate us from the confusion here.

[Auto-generated comment by a script] We noticed that this issue is targeted for M-69; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-69 label, otherwise remove Merge-TBD label. Thanks.

Removing all stability labels as there is an  issue 878002  (see comment #35).

Issue 863294 has been merged into this issue.