Did the overlay changes break this?

Isn't samus on 3.14? We don't have HW overlays or drm atomic there.

smbarber@: Could you try to login as a guest or as a user without Playstore enabled, and see what happens?

But could the chrome-side changes for overlays have broken stuff on non-atomic kernels?

It's possible, I can't think of any specific change we landed recently that could cause that though.
I'm flashing a samus right now.

re #3: Guest profile is okay. Personal profile has play store enabled, but the container is really slow to start (several minutes). It doesn't encounter this problem, though.

I can't reproduce it on my samus. Are you by any chance using a test image?

Unfortunately not, I'm in verified mode. There are some bugs going around about stateful corruption when upgrading to 61, so maybe that's a factor. Although I'm not sure what corruption on stateful would cause this.

Can you try enabling the debug border quad in about://flags?

This used to be reproducible even across reboots, but I can't get it to reproduce after this weekend :\ Logging into my corp account works as expected.

Please feel free to close if there's nothing else useful here to chase.

In case it happens again, can you please try enabling chrome://flags/#composited-layer-borders ?

I'm now sure how you could do that without seeing anything, but if you managed to play a video, you might be able to do that too. :)

Marking it as WontFix, please re-open if you see it again.

Disabling ARC++ gets rid of the giant black box that's drawn over everything. Re-enabling it brings the black box back. But this persists even after signing out, so ARC++ should be shut down AFAIK.

It updated to 61.0.3163.90 beta when this started happening (I was on earlier beta before). In the first two login attempts I just got black screen. The machine first totally halted on signin. I have to do hard reset (10+ second power button). 

The next time, it did show some strange window? outline in the corner (attached image). The mouse cursor was at least there. I turned ChromeVox (with ctrl+alt+z) to navigate through the feedback report dialog... 

Here are the two feedback reports that I sent. Their and system logs are attached.

https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:zelidrag@google.com&lReport=74291260797

https://feedback.corp.google.com/product/208/neutron?lView=rd&lRSort=1&lROrder=2&lRFilter=1&lReportSearch=user:zelidrag@google.com&lReport=74291190257

Deleted: 74291260797-system_logs.zip 1.2 MB

74291260797-system_logs.zip 1.2 MB Download

Deleted: 74291190257-system_logs.zip 1.2 MB

74291190257-system_logs.zip 1.2 MB Download

Deleted: IMG_20170925_180743.jpg 4.0 MB

	IMG_20170925_180743.jpg 4.0 MB View Download

 Issue 758678  has been merged into this issue.

According to marcheu@'s analysis, only windows that are supposed to be *1) promoted to hw overlay works, and nothing else work.

+penghuang@ who worked on  crbug.com/731742 , in case it's related.


*1) Samus doesn't have hw overlay support, so hw overlay isn't actually happening.

Reassigning to Stephane that is investigating on Zel's Chromebook.

Maybe the issue is with content tiles if/when Ganesh is enabled. Videos and Android apps would still be visible since those buffers are produced in a different way.

 Issue 770842  has been merged into this issue.

 Issue 770842  has been merged into this issue.

I can reproduce the symptoms for this issue intermettently (i.e. sometimes I can log in, sometimes I can not).

I do not see the symptoms described in  issue 767680 .

See  issue 770842  for details.

michaelpg@ here, posting from my personal account:

I don't understand why these issues are being duped into seemingly unrelated issues. This issue, like  issue 770842 , occurs in M61 (61.0.3163.108 for me right now).

My corp account still repros: I only see a black screen after signing in, with an apparently functional cursor. But my personal account works normally.

I can provide whatever logs I can access but I'm not sure which ones are relevant (I can only access them after rebooting the device and signing in with a working account).

This should be M61, RBS, and not duped into M62/M63 issues.

If this is indeed a dupe of  issue 767680 , we should ensure that bug is M-61, RBS, and describes the problem in this issue before closing this one.

Crashes that may be relevant (I can't access crash/ without my corp cert):

ffc686aabe57a460
9f980dcef95ff1c6

This DOES sound very similar to  bug 758678 

...Make up your mind :-P

It did happen for me after the weird OS upgrade flow (for Android apps maybe?). Main difference is that it happens every time with my corp account, persisting across reboots.

If I sign in to my corp account, the lock screen does show signs of  issue 767680 .

Actually it's not just the lock screen. I think the sign-in screen is also black if, after I sign in to my hosed (corp) account, I manage to sign out.

After re-reading the description this does sound similar to 758678, I just haven't managed to activate any videos. I did however notice that the cursor changes when I move it around.

Other observations:
* When it was happening it would happen frequently if I signed into my @google.com account first after a reboot, less frequently if I signed into another account first, then logged off and signed into my corp account.
* I had a flag set in chrome://flags (which causes chrome to restart on login). I cleared all flags ('Reset all to default') and have not managed to reproduce this since.

chrome log from repro session attached.

Interesting snippet:

[10784:10820:1004/115221.514788:ERROR:simple_version_upgrade.cc(164)] File structure does not match the disk cache backend.
[10784:10820:1004/115221.514841:ERROR:simple_backend_impl.cc(630)] Simple Cache Backend: wrong file structure on disk: /home/chronos/u-5a99b64b8ea504abb28b655e42905f7c48360cc4/Service Worker/CacheStorage/eadf114e35641d8a14aa9648d8e1c01b4b3bb3f0/c7f4e5ab-40f0-4ed7-9c73-ea5e3b66fbfc
[10784:10821:1004/115221.515160:ERROR:disk_cache.cc(132)] Unable to create cache

Later:

Failed to open uid map file /proc/11419/uid_map for process 11419
Invalid pid 11419, operation not allowed

Deleted: chrome.txt 7.7 KB

chrome.txt 7.7 KB View Download

GPU stuff kind of looks like a red herring here, we're suspecting command line length is too long when flags are present.

The workaround that seems to work is to clear your custom flags.

After signing in to the account that shows the black screen, you can enable ChromeVox with Ctrl+Alt+Z and follow the steps below (ChromeVox isn't necessary, but helps verify you typed the right things):

1. Open a new tab (Ctrl +T)
2. Type "chrome://flags", hit Enter
3. Hit Tab (to focus "Reset all to default" button), then Enter
4. Reboot the machine

Before clearing the custom flags, can you log in and get Chrome's command line while it's in the broken state?

(If this has only been seen on non-dev-mode devices, sending a feedback report while it's in the state may be enough to get the command line.)

I think custom flags are red herring because I had no custom flags when I got this problem. Re-login can fix this, and I guess that's what you had.

@32: It's not about custom flags, it's about the number of flags. The flags are inserted by lots of things, including:
- the login manager which adds flags on some platforms
- chrome internally adds some flags

But yes, at the end of the day I agree with the statement "custom flags are a red herring", because it's the number of flags that matters.

If we're hitting a command line length limit, it wouldn't be the first time. In issue 154409 (from 2012), I increased the maximum zygote message size from 2 KB to 8 KB due to our command lines getting too long.

@derat the command line mine had was:

/opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=27.0.0.130 --ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --max-unused-resource-memory-usage-percentage=5 --login-profile=user --enable-natural-scroll-default --has-chromeos-keyboard --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/default_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/default_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --enable-consumer-kiosk --arc-availability=officially-supported --arc-transition-migration-required --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --login-user=michaelpg@google.com --login-profile=5a99b64b8ea504abb28b655e42905f7c48360cc4 --flag-switches-begin --disable-gpu-rasterization --flag-switches-end --vmodule=*arc/*=1,tablet_power_button_controller=1,*chromeos/login/*=1,auto_enrollment_controller=1,*plugin*=2,*zygote*=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2

Hmm. That doesn't seem obscenely long to me (~1.5 KB), and it also doesn't look like there's any weirdness with multiple --enable-features switches (re  issue 767266 ).

Michael, where did --disable-gpu-rasterization came from? That looks like it's the only flag set by chrome://flags (per its position between --flag-switches-begin and --flag-switches-end). Had you manually set that?

What's the evidence for the number of flags being the cause?

Is it number of flags or total length of the command line?

My experience was that sometimes I could log in and sometimes I would get a black screen, with no clear pattern. I did a *lot* of logins, sometimes immediately after reboot, sometimes after logging in first with a different user. It's possible that there is a pattern that I missed, but it seemed at least somewhat random.

So if the repro is not reliable, *anything* could be a red herring here.

That said, I still have not been able to reproduce this since resetting chrome://flags, which suggests to me that this could be a chrome startup bug, except that oshima mentioned that he had seen it with no flags set.

@37: It seems to repro pretty consistently when adding any flag, and go away when removing any flag... I don't know what other proof you need that this is flag-related.

which flag(s) did you add?

Adding any flag causes chrome to be restarted after login. That seems to open a whole category of potential problems unrelated to command line length.

michaelpg@ You've been able to repro pretty consistently. Can you grab marcheu@'s patch at https://chromium-review.googlesource.com/#/c/chromium/src/+/701396/ and try to verify if it's really the cause here?

I could reproduce the issue on test image and here is the error I found in dmesg (looks same as crbug.com/771210, which may be just causing the same behavior on external display).




[   25.619472] ------------[ cut here ]------------
[   25.619484] WARNING: CPU: 3 PID: 2010 at /mnt/host/source/src/third_party/kernel/v3.14/drivers/gpu/drm/i915/intel_display.c:767 intel_wait_for_vblank+0xe0/0x1ce()
[   25.619494] vblank wait timed out
[   25.619497] Modules linked in: veth uinput snd_soc_sst_bdw_rt5677_mach snd_soc_sst_haswell_pcm snd_soc_sst_dsp memc_x86 snd_hda_codec_hdmi x86_pkg_temp_thermal cmac i2c_dev snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep acpi_als industrialio_triggered_buffer snd_soc_rt5677 snd_soc_sst_acpi snd_soc_rl6231 snd_soc_rt5677_spi rfcomm ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat zram xt_mark bridge stp fuse llc iio_trig_sysfs ip6table_filter cros_ec_accel kfifo_buf industrialio snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq ip6_tables snd_seq_device iwlmvm asix usbnet mii iwlwifi iwl7000_mac80211 cfg80211 btusb btbcm btintel bluetooth uvcvideo videobuf2_vmalloc joydev
[   25.619598] CPU: 3 PID: 2010 Comm: TaskSchedulerSe Not tainted 3.14.0 #1
[   25.619604] Hardware name: GOOGLE Samus, BIOS Google_Samus.6300.174.0 04/02/2015
[   25.619610]  0000000000000000 00000000fec99f68 ffff8804552ad890 ffffffff95c28d4c
[   25.619619]  ffff8804552ad8d8 ffff8804552ad8c8 ffffffff9565d7e8 ffffffff959630e1
[   25.619628]  ffff880467bd8000 0000000000070040 00000000000003b9 00000000fffbd011
[   25.619638] Call Trace:
[   25.619645]  [<ffffffff95c28d4c>] dump_stack+0x4d/0x6f
[   25.619652]  [<ffffffff9565d7e8>] warn_slowpath_common+0x7f/0x98
[   25.619659]  [<ffffffff959630e1>] ? intel_wait_for_vblank+0xe0/0x1ce
[   25.619666]  [<ffffffff9565d858>] warn_slowpath_fmt+0x57/0x73
[   25.619673]  [<ffffffff9599aa28>] ? gen6_read32+0xa4/0xb2
[   25.619679]  [<ffffffff959630e1>] intel_wait_for_vblank+0xe0/0x1ce
[   25.619685]  [<ffffffff95967829>] hsw_disable_ips+0x12b/0x14d
[   25.619692]  [<ffffffff959691c9>] haswell_crtc_disable+0x6e/0x293
[   25.619699]  [<ffffffff9596a1d2>] __intel_set_mode+0x98b/0x121e
[   25.619707]  [<ffffffff95737c84>] ? __slab_alloc.constprop.69+0xd9/0x434
[   25.619714]  [<ffffffff959385e2>] ? kzalloc.constprop.9+0xe/0x10
[   25.619722]  [<ffffffff9596cbb9>] intel_set_mode+0x14/0x2a
[   25.619728]  [<ffffffff9596d57a>] intel_crtc_set_config+0x8a7/0x965
[   25.619735]  [<ffffffff9592bd9e>] drm_mode_set_config_internal+0x5b/0xe5
[   25.619742]  [<ffffffff9592c270>] drm_framebuffer_remove+0x185/0x230
[   25.619749]  [<ffffffff9592f9a2>] drm_fb_release+0xa9/0xc9
[   25.619756]  [<ffffffff95921b76>] drm_release+0x28b/0x50b
[   25.619763]  [<ffffffff95749469>] __fput+0xdd/0x1c6
[   25.619769]  [<ffffffff95749588>] ____fput+0xe/0x10
[   25.619775]  [<ffffffff95678a29>] task_work_run+0x7d/0x93
[   25.619782]  [<ffffffff9565fad2>] do_exit+0x40d/0x94d
[   25.619789]  [<ffffffff9566aa73>] ? __dequeue_signal+0x1a/0x136
[   25.619795]  [<ffffffff9566008a>] do_group_exit+0x42/0xb0
[   25.619801]  [<ffffffff9566d7ad>] get_signal_to_deliver+0x567/0x58d
[   25.619809]  [<ffffffff95601eb3>] do_signal+0x57/0x527
[   25.619816]  [<ffffffff9577fa30>] ? SyS_epoll_ctl+0x839/0x8ca
[   25.619823]  [<ffffffff956890e5>] ? wake_up_state+0x12/0x12
[   25.619829]  [<ffffffff956023ac>] do_notify_resume+0x29/0x5b
[   25.619836]  [<ffffffff95c318ee>] int_signal+0x12/0x17

I also tested with extra flags and it didn't cause this problem. It's most likely restart process that is causing this.

/opt/google/chrome/chrome --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=27.0.0.130 --ui-prioritize-in-gpu-process --use-gl=egl --enable-native-gpu-memory-buffers --gpu-sandbox-failures-fatal=yes --enable-logging --log-level=1 --use-cras --enable-wayland-server --user-data-dir=/home/chronos --max-unused-resource-memory-usage-percentage=5 --system-developer-mode --login-profile=user --enable-natural-scroll-default --has-chromeos-keyboard --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/default_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/default_small.jpg --child-wallpaper-large=/usr/share/chromeos-assets/wallpaper/child_large.jpg --child-wallpaper-small=/usr/share/chromeos-assets/wallpaper/child_small.jpg --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --enable-consumer-kiosk --arc-availability=officially-supported --arc-transition-migration-required --enterprise-enrollment-initial-modulus=15 --enterprise-enrollment-modulus-limit=19 --flag=value --long-flag=long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --long-long-flag=long-long-value --login-manager --vmodule=*arc/*=1,tablet_power_button_controller=1,*chromeos/login/*=1,auto_enrollment_controller=1,*plugin*=2,*zygote*=1,*/ui/ozone/*=1,*/ui/display/manager/chromeos/*=1,power_button_observer=2,webui_login_view=2,lock_state_controller=2,webui_screen_locker=2,screen_locker=2

Disabling arc using --arc-availability=none seems to fix this. I've actually got black screen once out of 15 tries, at least it makes far less often. (and not sure if that's the same one)

Looks like we're starting ARC first, then restart, which kills arc and start again.
I'll look into if we can move it after restart and see if it can fix the issue.

+hidehiko
hidehiko@, when the user's chrome://flags is not the default one, Chrome tries to restart itself (via session_manager) shortly after sign-in as you know. However, before the browser restarts, the browser also seems to try to start the container. As a result, the container is started, then is killed (when the browser is killed), and is started again (when the browser restarts.)

oshima@ is thinking that this quick start/kill/restart might be causing, or related to the graphics issue (he's still checking.)  What do you think is the cleanest way to suppress the first container startup?  This is M61 where login screen instance is not available btw.

hidehiko@ can you and yusukes@ look into this today in TOK? We can pick up again in the AM. It sounds like the too long command line theory is less certain than we thought.

Not starting arc when restarting fixed this. I don't think restarting itself is the root cause though, but it's certainly related.

I'm not sure that's good fix but will send CL anyway.

CL: https://chromium-review.googlesource.com/c/chromium/src/+/704006

Re. why I had the issue even without a custom flag. I've got file system error and I wonder if that might have made chrome believe I have a custom flag.

One more: I found that 61 has a flip issue with frecon, which can also causes black screen. I've got black screen two times even with this, and I'm guessing this is due to this. If so, it shouldn't be an issue on production machine. (but not 100% certain)

So this can happen when we restart container quickly, and my CL doesn't cover other scenarios such as restarting after updating chrome://flags, chrome://restart and chrome crash. 

I'll investigate a bit more if we can mitigate it.

If we'd like to rescue more cases, how about;
- recording the container stop timing in session_manager, and
- if StartArcInstance() is called quickly, then add some delay (e.g. 500ms-1s) there?

It is still the workaround I think, though.

Here are summary from my investigation/testing. This is pure anecdotal and I do not have technical explanation:

1) On fresh image, this happens far less often even with custom flags.
2) I drained battery so that the device gets automatically shutdtown (this is from my experience). After this, this issue can easily be reproduced. (That is, black screen after login with custom flag)
3) With my patch in 49, login start working.
4) However, killing chrome by "chrome::restart", or "kill <pid>" can still cause black screen.
5) killing frecon seems to mostly fix this issue. I've seen black screen after "kill <pid>" a few times,
  but adding delay to arc/exo startup didn't improve much.

frecon stay alive only on dev mode. On regular mode, it'll quit after boot, so I think my Cl would be enough
to mitigate this issue. I'll also see if m62 has the same issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a26daee641b2f2b02e621d44f224d268a2ebc87e

commit a26daee641b2f2b02e621d44f224d268a2ebc87e
Author: Mitsuru Oshima <oshima@chromium.org>
Date: Sat Oct 07 00:53:46 2017

Do not start ARC cotnainer if chrome will be restarted due to flag

BUG= 758820 

Change-Id: Ica7f8eacec28e8eb7516a3682c00f583d6c2666e
Reviewed-on: https://chromium-review.googlesource.com/704006
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#507248}
[modify] https://crrev.com/a26daee641b2f2b02e621d44f224d268a2ebc87e/chrome/browser/chromeos/arc/arc_util.cc
[modify] https://crrev.com/a26daee641b2f2b02e621d44f224d268a2ebc87e/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/a26daee641b2f2b02e621d44f224d268a2ebc87e/chrome/browser/chromeos/login/session/user_session_manager.h

I tried the same repro step on 62.0.3202.43 / 9901.35 (17.10.02) and I couldn't reproduce the issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8fbd0feec6778f8ffd8a0b32675a9c385e4e75c0

commit 8fbd0feec6778f8ffd8a0b32675a9c385e4e75c0
Author: Mitsuru Oshima <oshima@chromium.org>
Date: Sun Oct 08 23:40:56 2017

Do not start ARC cotnainer if chrome will be restarted due to flag

BUG= 758820 

Change-Id: Ica7f8eacec28e8eb7516a3682c00f583d6c2666e
Reviewed-on: https://chromium-review.googlesource.com/704006
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#507248}(cherry picked from commit a26daee641b2f2b02e621d44f224d268a2ebc87e)
Reviewed-on: https://chromium-review.googlesource.com/706304
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Cr-Commit-Position: refs/branch-heads/3163@{#1315}
Cr-Branched-From: ff259bab28b35d242e10186cd63af7ed404fae0d-refs/heads/master@{#488528}
[modify] https://crrev.com/8fbd0feec6778f8ffd8a0b32675a9c385e4e75c0/chrome/browser/chromeos/arc/arc_util.cc
[modify] https://crrev.com/8fbd0feec6778f8ffd8a0b32675a9c385e4e75c0/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/8fbd0feec6778f8ffd8a0b32675a9c385e4e75c0/chrome/browser/chromeos/login/session/user_session_manager.h

CL is merged to M-61 and included in latest M61 build 	9765.81.0/61.0.3163.120

Oshima, anything else expected or are we good to mark this as fixed now?

Can we merge this to M62 too?

This bug requires manual review: We are only 7 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop)

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

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ea3839b24c22c38874e6fb954786393c088882ae

commit ea3839b24c22c38874e6fb954786393c088882ae
Author: Mitsuru Oshima <oshima@chromium.org>
Date: Tue Oct 10 16:47:16 2017

Do not start ARC cotnainer if chrome will be restarted due to flag

BUG= 758820 

Change-Id: Ica7f8eacec28e8eb7516a3682c00f583d6c2666e
Reviewed-on: https://chromium-review.googlesource.com/704006
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#507248}(cherry picked from commit a26daee641b2f2b02e621d44f224d268a2ebc87e)
Reviewed-on: https://chromium-review.googlesource.com/709674
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#635}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/ea3839b24c22c38874e6fb954786393c088882ae/chrome/browser/chromeos/arc/arc_util.cc
[modify] https://crrev.com/ea3839b24c22c38874e6fb954786393c088882ae/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/ea3839b24c22c38874e6fb954786393c088882ae/chrome/browser/chromeos/login/session/user_session_manager.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/0fc86dec47963d4c4deb6e945a58aa8366d42eee

commit 0fc86dec47963d4c4deb6e945a58aa8366d42eee
Author: khmel <khmel@google.com>
Date: Mon Oct 23 21:37:08 2017

Revert "Do not start ARC cotnainer if chrome will be restarted due to flag"

This reverts commit a26daee641b2f2b02e621d44f224d268a2ebc87e.

This CL looks dangerous once IsArcAllowedForProfile needs to be
persistent for all calls during the user session lifetime. Otherwise
some ARC component may have wrong assumption. Crashes in go/rfunq
contain in log "ARC because chrome will restart" so this looks as the
reason of this.

Based on offline discussion with oshima@ now this CL is less important
starting from M62. Let merge this revert and see how this affects
stability.

Test: N/A
Bug: 775861
Bug:  758820 
Change-Id: Icab0dfe95402c1fdcfde11333522f74ae8236fb1
Reviewed-on: https://chromium-review.googlesource.com/734283
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Commit-Queue: Yury Khmel <khmel@google.com>
Cr-Commit-Position: refs/heads/master@{#510928}
[modify] https://crrev.com/0fc86dec47963d4c4deb6e945a58aa8366d42eee/chrome/browser/chromeos/arc/arc_util.cc
[modify] https://crrev.com/0fc86dec47963d4c4deb6e945a58aa8366d42eee/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/0fc86dec47963d4c4deb6e945a58aa8366d42eee/chrome/browser/chromeos/login/session/user_session_manager.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cd2f226d1e399380fd082237ec3a1ccd9fd24ef3

commit cd2f226d1e399380fd082237ec3a1ccd9fd24ef3
Author: khmel <khmel@google.com>
Date: Wed Oct 25 03:14:32 2017

[Merge M63] Revert "Do not start ARC cotnainer if chrome will be restarted due to flag"

This reverts commit a26daee641b2f2b02e621d44f224d268a2ebc87e.

This CL looks dangerous once IsArcAllowedForProfile needs to be
persistent for all calls during the user session lifetime. Otherwise
some ARC component may have wrong assumption. Crashes in go/rfunq
contain in log "ARC because chrome will restart" so this looks as the
reason of this.

Based on offline discussion with oshima@ now this CL is less important
starting from M62. Let merge this revert and see how this affects
stability.

TBR=khmel@google.com

(cherry picked from commit 0fc86dec47963d4c4deb6e945a58aa8366d42eee)

Test: N/A
Bug: 775861
Bug:  758820 
Change-Id: Icab0dfe95402c1fdcfde11333522f74ae8236fb1
Reviewed-on: https://chromium-review.googlesource.com/734283
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Commit-Queue: Yury Khmel <khmel@google.com>
Cr-Original-Commit-Position: refs/heads/master@{#510928}
Reviewed-on: https://chromium-review.googlesource.com/737273
Reviewed-by: Yury Khmel <khmel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3239@{#205}
Cr-Branched-From: adb61db19020ed8ecee5e91b1a0ea4c924ae2988-refs/heads/master@{#508578}
[modify] https://crrev.com/cd2f226d1e399380fd082237ec3a1ccd9fd24ef3/chrome/browser/chromeos/arc/arc_util.cc
[modify] https://crrev.com/cd2f226d1e399380fd082237ec3a1ccd9fd24ef3/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/cd2f226d1e399380fd082237ec3a1ccd9fd24ef3/chrome/browser/chromeos/login/session/user_session_manager.h

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8f7516cb4f07089fc06ade31e7abaa2ed8cdd942

commit 8f7516cb4f07089fc06ade31e7abaa2ed8cdd942
Author: khmel <khmel@google.com>
Date: Tue Oct 31 21:00:34 2017

[Merge M62] Revert "Do not start ARC cotnainer if chrome will be restarted due to flag"

This reverts commit a26daee641b2f2b02e621d44f224d268a2ebc87e.

This CL looks dangerous once IsArcAllowedForProfile needs to be
persistent for all calls during the user session lifetime. Otherwise
some ARC component may have wrong assumption. Crashes in go/rfunq
contain in log "ARC because chrome will restart" so this looks as the
reason of this.

Based on offline discussion with oshima@ now this CL is less important
starting from M62. Let merge this revert and see how this affects
stability.

TBR=khmel@google.com

(cherry picked from commit 0fc86dec47963d4c4deb6e945a58aa8366d42eee)

Test: N/A
Bug: 775861
Bug:  758820 
Change-Id: Icab0dfe95402c1fdcfde11333522f74ae8236fb1
Reviewed-on: https://chromium-review.googlesource.com/734283
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Commit-Queue: Yury Khmel <khmel@google.com>
Cr-Original-Commit-Position: refs/heads/master@{#510928}
Reviewed-on: https://chromium-review.googlesource.com/747686
Reviewed-by: Yury Khmel <khmel@chromium.org>
Cr-Commit-Position: refs/branch-heads/3202@{#763}
Cr-Branched-From: fa6a5d87adff761bc16afc5498c3f5944c1daa68-refs/heads/master@{#499098}
[modify] https://crrev.com/8f7516cb4f07089fc06ade31e7abaa2ed8cdd942/chrome/browser/chromeos/arc/arc_util.cc
[modify] https://crrev.com/8f7516cb4f07089fc06ade31e7abaa2ed8cdd942/chrome/browser/chromeos/login/session/user_session_manager.cc
[modify] https://crrev.com/8f7516cb4f07089fc06ade31e7abaa2ed8cdd942/chrome/browser/chromeos/login/session/user_session_manager.h

Hmm, do we have a proper fix? If not why are we reverting the workaround? In my experience the problem did happen on 62...

m62 doesn't have this issue because it runs mini container in login screen.
(To be more precise, the CL doesn't make difference)

I tested the same repro on 62 and I couldn't repro.

s/mini container/mini instance/

Is that a recent change that was backported to 62/63?

Yes, mini instance is enabled on 62.

comment#72
Mini instance is a feature added in M62, and has been in production for a few months now. It's not a recent (backported) feature.

@74: so if mini instance prevents the problem in 62/63, why did I see the problem there?

Are you still having this issue?