Hi,

Unfortunately, I do not have access to https://uberchromegw.corp.google.com/i/tryserver.chromium.angle/builders/linux_angle_chromeos_rel_ng/builds/2004. Could you please give more information about the issue ? (does the build use specific GN args for instance).

Also is it a recent regression ? If we exclude my three attempts to upgrade protobuf (that have been reverted), third_party/protobuf didn't change at all since end of nov. 2016 (https://crrev.com/ffa07a52a801ce805fd5f01f9984d4df2a71b620) in chromium src.

Ah, sorry, I've posted an internal URL.
Here is the external one:
https://build.chromium.org/p/tryserver.chromium.angle/builders/linux_angle_chromeos_rel_ng/builds/2004

gn args are:
build_angle_deqp_tests = true
dcheck_always_on = true
ffmpeg_branding = "Chrome"
goma_dir = "/b/c/cipd/goma"
internal_gles2_conform_tests = true
is_component_build = false
is_debug = false
proprietary_codecs = true
symbol_level = 1
target_os = "chromeos"
use_goma = true

I think it is a recent regression, and it is also flaky. I see this problem only in 3 other builds:
https://build.chromium.org/p/tryserver.chromium.angle/builders/linux_angle_chromeos_rel_ng/builds/2002
https://build.chromium.org/p/tryserver.chromium.angle/builders/linux_angle_chromeos_rel_ng/builds/1996
https://build.chromium.org/p/tryserver.chromium.angle/builders/linux_angle_chromeos_rel_ng/builds/1995

PS. You won't be able to use "internal_gles2_conform_tests = true" (not sure about "proprietary_codecs = true"), but I don't think is matters for this issue.

Thanks for the info.

> I think it is a recent regression, and it is also flaky.

I see that https://codereview.chromium.org/2645053003 landed about 2 weeks ago. Could you add rhalavati@ in CC to get his view on this ?

Ah, perhaps both cloud_policy.proto and cloud_policy_full_runtime.proto create cloud_policy.pb.h?

rhalavati@, could you please take a look?

The mentioned CL added a new output to the script that generated cloud_policy.proto to create an extra version of it with full runtime features.

I am not sure if it is the reason for this problem, but as multiple cloud_policy generations might be responsible for it, I created this CL (https://codereview.chromium.org/2690563002/) to stop generating the second version by default and return the script's default action to the state before my previous CL.

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

commit 7218269c5a015a91630aa94b1e3d696237a29d52
Author: rhalavati <rhalavati@chromium.org>
Date: Mon Feb 13 12:47:47 2017

Full runtime cloud policy proto will not be generated by default..

Recent CL (https://codereview.chromium.org/2645053003) had added a new output to cloud policy proto script generator which was suitable for full runtime compilation.
This is probably causing a race condition in compiling when this output is not required.
This CL separates the codes responsible for generating the two outputs and the second one is generated only if it is explicitly requested.

BUG= 690296 

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

[modify] https://crrev.com/7218269c5a015a91630aa94b1e3d696237a29d52/components/policy/BUILD.gn
[modify] https://crrev.com/7218269c5a015a91630aa94b1e3d696237a29d52/components/policy/tools/generate_policy_source.py

The above CL introduces a new action to cloud_policy_code_generate for creating the 2nd output proto, and returns all its previous actions' behaviors to the state before CL/2645053003 that was landed 2 weeks ago.
Therefore I expect that if CL/2645053003 was responsible for the issue, this one  reverts it.

A new Linux bot was added very recently: http://build.chromium.org/p/chromium.linux/waterfall?builder=linux_chromium_clobber_deterministic

This bot shows a reliable failure in the first step mentioning DEPS; the signature looks very similar to comment #2 of this bug.

(If you include a generated pb.h file in a .h file that's in some project A's public headers, then everything depending on A must depend on it through public_deps instead of deps -- see `gn help public_deps`. Not sure if that's the issue here.)

I've checked all the failed builds since 2004 and it seems that this is not happening again.
The part of the BUILD.gn that could generated the second proto is now isolated and not used in any landed CL, so I think we can safely assume this bug is fixed.
I will keep checking by tomorrow and if nothing happens and there would be no objection, will close it.