New issue
Advanced search Search tips

Issue 703706 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug

Blocked on:
issue 700120

Blocking:
issue 79722



Sign in to add a comment

GPU process won't boot on ToT

Project Member Reported by kbr@chromium.org, Mar 21 2017

Issue description

Chrome Version: ToT at 4832979ab80769a47bcd70b3a5510d9b523f2b06
OS: Linux

What steps will reproduce the problem?
(1) Build at ToT
(2) Run

What is the expected result?

Expect the GPU process to boot.


What happens instead?

[12403:12403:0321/101311.406191:ERROR:gl_surface_glx.cc(87)] glXGetFBConfigs failed.
[12403:12403:0321/101311.406313:ERROR:gl_surface_glx.cc(128)] glXCreateWindow failed
[12403:12403:0321/101311.406340:ERROR:gl_surface_glx.cc(442)] CreateDummyWindow(g_display) failed
[12403:12403:0321/101311.406356:ERROR:gl_initializer_x11.cc(156)] GLSurfaceGLX::InitializeOneOff failed.
[12403:12403:0321/101311.413585:ERROR:gpu_child_thread.cc(309)] Exiting GPU process due to errors during initialization
[12337:12376:0321/101311.414313:ERROR:browser_gpu_channel_host_factory.cc(126)] Failed to create channel.


I've been struggling with this problem since yesterday and seeing very strange behavior on my workstation, where occasionally it wasn't just my build that was broken. At this point though it's only my build that's hosed. Just did a (mostly) full rebuild; going to try a full one now. Component Release build on Trusty.

I switched from a 24" to a 30" monitor last week and think that that changed my desktop configuration somehow. The system still thinks DISPLAY is :0.

Could anyone help me figure out what's going wrong?

 
Labels: -Pri-2 Pri-1
Status: Available (was: Untriaged)
I can reproduce by building a fresh ToT chrome and running it with --user-data-dir=/tmp/fooI haven't changed monitors however I noticed Goobuntu got some updates (the login manager design changed).

Ken, unfortunately it doesn't seem related nor to the info collection changes, nor to the enabling of the core profile: this call is done independently of all the rest and is plain glX. Disabling the sandbox didn't help.

Comment 2 by vmp...@chromium.org, Mar 21 2017

Cc: piman@chromium.org
crrev.com/458016 is the first bad revision for me in component build (non component works fine). piman@ is confirming

Comment 3 by piman@chromium.org, Mar 21 2017

Owner: thomasanderson@chromium.org
Confirmed, bisected to that CL.

Comment 4 by vmp...@chromium.org, Mar 21 2017

Status: Assigned (was: Available)

Comment 5 by piman@chromium.org, Mar 21 2017

I checked, and it only affects Release+components builds. Debug+components or Release+no-components appear to work correctly.

Comment 6 by kbr@chromium.org, Mar 21 2017

Blocking: 79722 700120

Comment 7 by kbr@chromium.org, Mar 21 2017

Blockedon: 700120
Blocking: -700120
Status: Started (was: Assigned)

Comment 9 by piman@chromium.org, Mar 21 2017

investigation so far: with crrev.com/458016 in, and keeping protobuf_globals as a component, but making protobuf_lite back into a component, things work again. So it seems like protobuf_lite still contains something strange when statically linked.

Comment 10 by piman@chromium.org, Mar 22 2017

More data: it looks like third_party/protobuf/src/google/protobuf/arena.cc/h is to blame. If I move everything from third_party/protobuf/src/google/protobuf/stubs into a component, and leave all the rest of protobuf_lite in the static lib, it fails. If I move arena.cc/h from the static lib into the component, it works.

In particular, arena.cc depends on PROTOBUF_USE_DLLS in its implementation, so I suspect that's what causing a behavior change.

Comment 11 by piman@chromium.org, Mar 22 2017

Ok, I think it's just that google::protobuf::Arena::thread_cache_ is a global, and so it needs to go into the protobuf_globals component so that it's shared across multiple instantiations of the code.
Project Member

Comment 12 by bugdroid1@chromium.org, Mar 22 2017

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

commit 57c80c99d9f3355e5dc1829d0ac2eeffe7cd26b6
Author: thomasanderson <thomasanderson@google.com>
Date: Wed Mar 22 07:51:24 2017

Protobuf: Move thread-local global data to globals.cc

This CL is a followup to https://codereview.chromium.org/2756543002/ which moved
all variables in .data and .bss into globals.cc.  However, I overlooked thread-local
variables in .tdata and .tbss.  This CL moves those too.

CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng;master.tryserver.chromium.win:win_chromium_dbg_ng
R=pkasting@chromium.org
CC=piman@chromium.org
BUG= 703706 

Review-Url: https://codereview.chromium.org/2759423004
Cr-Commit-Position: refs/heads/master@{#458677}

[modify] https://crrev.com/57c80c99d9f3355e5dc1829d0ac2eeffe7cd26b6/third_party/protobuf/BUILD.gn
[modify] https://crrev.com/57c80c99d9f3355e5dc1829d0ac2eeffe7cd26b6/third_party/protobuf/README.chromium
[modify] https://crrev.com/57c80c99d9f3355e5dc1829d0ac2eeffe7cd26b6/third_party/protobuf/patches/0012-extract-globals.patch
[modify] https://crrev.com/57c80c99d9f3355e5dc1829d0ac2eeffe7cd26b6/third_party/protobuf/src/google/protobuf/arena.cc
[modify] https://crrev.com/57c80c99d9f3355e5dc1829d0ac2eeffe7cd26b6/third_party/protobuf/src/google/protobuf/arena.h
[modify] https://crrev.com/57c80c99d9f3355e5dc1829d0ac2eeffe7cd26b6/third_party/protobuf/src/google/protobuf/globals.cc

Status: Fixed (was: Started)
Thank you piman@ for the debugging, it was a big help!
This should be fixed after the change in c#12

Sign in to add a comment