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

Issue 652144 link

Starred by 1 user
Status: WontFix
Owner:
sadrul@chromium.org
Closed: Jan 12
Cc:
posciak@chromium.org
█ reve...@chromium.org
█ marc...@chromium.org
dsinclair@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Cannot start Chrome with GPU sandbox disabled on ARM Chrome OS anymore

Project Member Reported by posciak@chromium.org, Oct 3 2016 
Chrome does not start on ARM Chrome OS if passed --no-sandbox or --disable-gpu-sandbox anymore, which I suspect is related to recent changes to introduce GpuInit.

This can be reproduced on ARM daisy Chrome OS devices. Steps to repro:

1. Add --disable-gpu-sandbox and/or --no-sandbox to /etc/chrome_dev.conf.

2. Restart Chrome/UI (this can be done from shell by saying "restart ui"). The UI does not come up. From /var/log/ui/ui.LATEST:

[1002/203906:FATAL:gpu_process_transport_factory.cc(334)] Unable to create a UI graphics context, and cannot use software compositing on ChromeOS.


(Note that Chrome OS startup scripts will reboot the system after a few unsuccessful tries to restart UI, which may result in a reboot loop with the above flags added to /etc/chrome_dev.conf. This behavior can be suppressed by disabling /etc/init/ui-respawn.conf, possibly via commenting out "start on stopping ui" line in it, or just moving the respawn scipt away).

Comment 1 by sadrul@chromium.org, Oct 3 2016 

Can you try with the --gpu-sandbox-start-early flag and see if that makes any difference?

It sounds like GpuInit::InitializeAndStartSandbox() is returning false. If you could add some LOG(ERROR)s in there to confirm what's causing the failure, that would be very useful (I don't have an arm test device at the moment, so it may be a few days before I am able to test/debug this on actual device).

Comment 2 by posciak@chromium.org, Oct 3 2016 

Thanks! Unfortunately adding --gpu-sandbox-start-early alongside the above flags doesn't seem to help. I'll try to debug more.

Comment 3 by posciak@chromium.org, Oct 14 2016 

Did you perhaps have a chance to take a look at this/reproduce on your end? Thanks!

Comment 4 by posciak@chromium.org, Oct 27 2016 

Hi, did you perhaps have a chance to take a look? Thank you!

Comment 5 by enne@chromium.org, Nov 9 2016 

sadrul: ping.  Is this really a P1?

Comment 6 by sadrul@chromium.org, Nov 9 2016

Status: Started (was: Assigned)
Since this doesn't affect end users, I am moving to P2. But I should get a device tomorrow.

Comment 7 by danakj@chromium.org, Dec 16 2016

Labels: -Pri-1 Pri-2
I'll actually change to P2 :) But did you get the device and try?

Comment 8 by benhenry@google.com, Jan 11 

You started fixing this bug over two years ago. Are you still working on it? You can update the status to "archived", "wontfix", or "closed". You can remove yourself as owner and change status to "untriaged", but if this is still a real bug, please do not sit on it.

Comment 9 by sadrul@google.com, Jan 12

Status: WontFix (was: Started)
►

Sign in to add a comment