Seen this issue on  build 54.0.2840.68/8743.69.0 cyan

oka@, could you try to reproduce this on samus or cyan?

OK.

Couldn't reproduce using 54.0.2840.68/8743.69.0 (Official build) dev-channel cyan test.

Did you update Chrome version and began to see the issue?

Hi abodeti@, rookrishna@
We look for information to reproduce this item.
- How frequently this this problem reproduce?
- Is external storage (e.g. USB memory, SD card, etc...) connected to the Chromebook?
- Is ZIP archive mounted in Files app?

- Have you tested other devices (especially, devices which don't support ARC)?
- Did you see a window with white background, or did you see nothing on clicking Files app icon? 

This was seen only on samus and cyan yesterday after an update . There was no response on clicking the file app .  But sign out and signing back in fixed the issue and its not repro'd reliably. 

If repro'd again will update the bug.

We can reproduce this again. No real repro steps (no zip files, no sd card).
The files app wasn't being used. 
Then we went to open it and it didn't open
Couldn't open chrome://inspect => Apps => Files app either 
This time repro'd on chell 

Feedback Report:- https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:chrometestr1&lReport=14406276249

This issue is reproducible 5 out of 10 times with suspend/Resume the chell device.

Is this happening in other devices?

repro'd on samus cyan and chell 

Is Chell running Arc? e.g. is this problem on devices not running Arc?

No this is on M54, chell doesn't have ARC. 

More details, when this happens Get Help and crosh don't open either 

oka/fukino, were there any recent changes related to this that may be related to this?

The recent change I cherry-picked to M54 is this. https://codereview.chromium.org/2422093002/
I doubt if it's the root cause though.

Do you know of any other change that may be affecting file app here?
https://chromium.googlesource.com/chromium/src/+log/54.0.2840.59..54.0.2840.68?pretty=fuller&n=10000

David, can you confirm if other apps failed on their own or after File apps fails?

I still can't repro...

Here is the full diff: https://chromium.googlesource.com/chromium/src/+log/54.0.2840.59..54.0.2840.68?pretty=fuller&n=10000

According to the chat with Devid,
suspend (close the lid for a few minutes) -> resume often triggers the issue.
===
I really don't have better repro steps. Some devices we could repro it: cyan, samus and chell and others we couldn't like daisy 
We were just trying to open the files app after a certain period of usage 
and it wouldn't open 
sometimes it would be the first time after logging in 
sometimes it would be after suspend resume 
===

rookrishna@ and  dhaddock@, did you test this on M53? Wanted to confirm it's a M54 regression.

As per chat with David, they were not able to repro on previous M54 Beta (54.0.2840.59)

This is chrome OS side changes: https://crosland.corp.google.com/log/8743.65.0..8743.69.0

We still had no lock with reproducing the problem.

I see following lines in both reported logs.
[30382:30382:1018/133523:WARNING:merge_session_throttling_utils.cc(138)] Loading content for a profile without session restore?
[30382:30382:1018/133523:ERROR:component_loader.cc(154)] Failed to parse extension manifest.

rdevlin.cronin@, piman@,
Do they mean serious problems?
If so, do you have any ideas about what can cause these logs?

oka@ reproduced the issue (only one time) using chell.

After it resumed from suspended state, we can't open any apps.
We can open Chrome browser, but when we enter a URL, the browser window stays blank.
We can't open chrome://version, chrome://settings, etc...

josafat@, it doesn't seem file manager specific issue, and maybe we need wider audience to look into this issue.

 Issue 658126  has been merged into this issue.

If this is not Chell specific, I would try on non-Skylake devices as SKL devices have some issues with suspend/resume.

+abodenha

Albert, Is there anyone else who could help here?

It seems very hard to repro but according to test team this was not seen in the last beta (m54)

here are the diffs:
Chrome: https://chromium.googlesource.com/chromium/src/+log/54.0.2840.59..54.0.2840.68?pretty=fuller&n=10000
OS: https://crosland.corp.google.com/log/8743.65.0..8743.69.0

+rkc too 

Looking through the changelog, nothing at all springs up. I spoke to Xiyuan about this, and this 'could' be a situation where we aren't unfreezing our renderers.

Adding derat@ in case he has any insight here.

Might be a duplicate of mystery  issue 652110 .

I fixed an (old?) renderer-thawing race (but only on aborted suspends, I think) for  issue 646912 . The fix is on M55 but not M54, though, so this probably isn't that if it shows up after you suspend successfully and is also on M55.

Feedback report 14348229145 had a cancelled suspend attempt at 1018/130030 but a bunch more suspend/resume cycles after that, and the log goes until 1019/101304, so I suspect this isn't the renderer-thawing race that I mentioned in #32.

Feedback report 14406276249 just has one suspend/resume cycle ending at 1020/111421, and the log goes on to 1020/112727. Did you use the system for 13 minutes without anything working after resuming before filing the report, or am I misreading things?

I'm not convinced that this is related to renderer freezing. If it were, I'd expect all of the existing renderers to remain frozen immediately after resuming, but it looks like the system is still being used for a decent amount of time after resuming here.

>>Feedback report 14406276249 just has one suspend/resume cycle ending at 1020/111421, and the log goes on to 1020/112727. Did you use the system for 13 minutes without anything working after resuming before filing the report, or am I misreading things?


The system is usable (could browse sites )after suspend resume but only issue  was unable to open the file.app/gethelp page or crosh window  

rookrishna@ - what windows/sites were open 'before' the suspend?

It could be that the sites that rookrishna@ visited were just all new renderers, and all renderers opened before the suspend were the ones that were frozen.

Few sites where cnn,msn ,youtube and crosh window was open before suspend

@24
>[30382:30382:1018/133523:ERROR:component_loader.cc(154)] Failed to parse extension manifest.

That's a fairly significant error, which means that we couldn't load one of the component extensions.  Depending on which app it is, this could be very bad indeed on CrOS, where component apps are an integral part of the OS.  This often happens because of some kind of binary corruption.

If you're able to repro it on a device in dev mode, please switch to VT2, run the following command, and then attach /tmp/cgroups.txt to this bug:

for i in /proc/[0-9]*; do echo $i $(cat $i/cmdline); cat $i/cgroup; echo; done >/tmp/cgroups.txt

Then we should be able to see if any renderers are frozen.

Logs attached from cyan device  54.0.2840.68/8743.69.0 

Deleted: crgroups.txt 74.9 KB

crgroups.txt 74.9 KB View Download

Accroding to https://bugs.chromium.org/p/chromium/issues/detail?id=658126,
this issue happened in the older version 55.0.2883.7/8872.6.0

Then it may be that this is not a new regression (at least not caused by your Files app change https://codereview.chromium.org/2422093002)   

Dan/rdevlin, could you evelueate further as per new logs in c#39?

rookrishna, can you also evaluate if you still see in newest build 	8743.72.0 too?  

Josafat, was the addition of the OS-Mac label in #42 accidental? I don't see anything about non-Chrome-OS devices here.

Roopa, if you're able to trigger this again or have a device still in this state, could you also run "cat /sys/fs/cgroup/freezer/chrome_renderers/to_be_frozen/freezer.state" and paste the contents here?

derat@ I am not sure why Josafat added the Mac tag. I will ping him offline to find out. I have also requested ovanieva@ to find out any customers reporting similar issues on M54 Beta (8743.69.0/54.0.2840.68)). I will update this thread once we find out.

Was not able to repro the issue again
Tested on M55 (8872.22.0)and also on M54 build even on 54.0.2840.68/8743.69.0  

Please have a fix (baked/verified in canary and merge M55 branch 2883) as this marked as M55 stable blocker.

Thank you.

removing  OS-Mac (added by accident)

I'm removing release blocking since this is not (easy) reproduce as per c#45 

Keeping it open to investigate logs as per c#43 request 

Just saw this issue again on stable build
Ran cat /sys/fs/cgroup/freezer/chrome_renderers/to_be_frozen/freezer.state

and the content shows 

FROZEN. 

We will leave the device in this state in case anyone wants us to run anything else or take it themselves for examination 

Thanks! I think that that means that we're not thawing the renderers. Do you concur, Chirantan?

55.0.2883.20, where this was initially reported, had my fix for the race described in  issue 646912 . If that's correct (what version was the output in #48 from?), then I assume that that's not what we're seeing here.

A big hammer to use here might be implementing and merging issue 649350 (disabling renderer-freezing).

Test Version #48 8743.74.0, 54.0.2840.77 cyan

according to issue https://bugs.chromium.org/p/chromium/issues/detail?id=646912#c8, it does not look that the issue there was something new and somewhat tricky.

Dan, do you think this issue is a recent regression (as opposed to hard to repro) as per logs/investigation?

 Issue 646912  was fixed by https://codereview.chromium.org/2340153002 (r418887). The fix isn't present in M54 (2840). It looks like the fix first appeared in the 2862 branch, so it has always been fixed in M55 (2883).

Most of the reports of this seem to be about M54, but there are a few "Unable to open Files app" reports implicating M55:

-  issue 658126  (55.0.2883.7)
- initial report here (55.0.2883.20)

It's likely that Roopa's report from #48 (54.0.2840.77) is  issue 646912 , so I think it's worthwhile to investigate merging that fix to 2840. I'll look into this and update  issue 646912 .

I'd still like to know what's going on with the reports from M55, though. If anyone's able to repro the problem on a dev-mode M55 device, please run "cat /sys/fs/cgroup/freezer/chrome_renderers/to_be_frozen/freezer.state" and paste the contents here to shed some light on whether it's renderer-freezing-related or something else.

If Roopa's case is likely  issue 646912  then issue is not a regression on M54 as  it was there in M53 and earlier and this should not block M54 stable.

That said, we can have a potential merge for a "second" stable (m54) based on Dan's investigation of M55 cases to confirm these are not caused/related to above changes. 

I don't understand -- I don't see any mentions of this happening on M53 (2785).

 Issue 646912  wasn't a regression in the power-management code (rather, it was a bug that had been there for a long time), but it's entirely possible that something changed (e.g. Chrome takes longer to prepare to suspend on certain new devices or due to a separate code change) in M54 to make it start occurring frequently.

It appears to have started showing up frequently in M54, which should be grounds for us to consider merging the fix there.

I agree that this looks like  issue 646912 .  I would be very surprised if the M55 issues are the same thing.

I've merged the fixes from  issue 646912  to M54 and have posted verification instructions on that issue.

These merges are in 8743.76.0/54.0.2840.79

Per verification of  issue 646912 's merge to M54, I'm going to mark this as a duplicate of it.

Let's file a new bug if there are Files app problems on M55 or later, since they're unlikely to be related to renderer-freezing.