Issue metadata
Sign in to add a comment
|
Windows builders fail flakily running ninja with -d explain at the end of compile step |
||||||||||||||||||||||||
Issue descriptionhttps://build.chromium.org/p/chromium.webrtc.fyi/builders/Win%20x64%20GN%20%28dbg%29/builds/5778 Per kjellander@: It's a flake during the end of the compile step. It's the second time I've seen this in a short while and https://build.chromium.org/p/chromium.webrtc.fyi/builders/Win%20x64%20GN%20%28dbg%29?numbuilds=200 shows many similar failures.
,
Jun 13 2016
Log snippet for convenience: [12/12] STAMP obj/chromium_builder_tests.stamp ninja explain: restat of output chrome.7z older than most recent input ../Debug_x64/views_content_client.dll (0 vs 487528152) ninja explain: chrome.7z is dirty ninja explain: setup.ex_ is dirty ninja explain: gen/chrome/installer/mini_installer/packed_files.rc is dirty ninja explain: obj/chrome/installer/mini_installer/archive.stamp is dirty ninja explain: gen/chrome/installer/mini_installer/packed_files.rc is dirty ninja explain: obj/chrome/installer/mini_installer/mini_installer/packed_files.res is dirty ninja explain: mini_installer.exe is dirty ninja explain: obj/chrome/installer/mini_installer/archive.stamp is dirty ninja explain: mini_installer.exe is dirty ninja explain: obj/chrome/installer/mini_installer/next_version_mini_installer.inputdeps.stamp is dirty ninja explain: next_version_mini_installer.exe is dirty ninja explain: obj/chrome/installer/mini_installer/next_version_mini_installer.stamp is dirty ninja explain: obj/both_gn_and_gyp.stamp is dirty ninja explain: obj/gn_all.stamp is dirty ninja explain: obj/All.stamp is dirty ninja explain: obj/chromium_builder_tests.stamp is dirty <Thread(Thread-1, started 5596)> ProcessRead: proc.stdout finished. <Thread(Thread-1, started 5596)> ProcessRead: cleaning up. <Thread(Thread-2, started daemon 6584)> TimedFlush: Finished <Thread(Thread-1, started 5596)> ProcessRead: finished. Failing build because ninja reported work to do. This means that after completing a compile, another was run and it resulted in still having work to do (that is, a no-op build wasn't a no-op). Consult the first "ninja explain:" line for a likely culprit.
,
Jun 13 2016
This is fyi; does this need trooper attention? This looks like more of a goma outage, so I'm removing the trooper label.
,
Jun 13 2016
I don't know. I just thought a trooper might be more familiar with what's going on at the end of the compile step. I'm fine leaving this for the Goma folks to chime in on.
,
Jun 14 2016
I looked into this and it's related to the second compile invocation (passing -d explain to ninja) that's supposed to verify that running a second compile is a no-op. Here's the code involved: https://cs.chromium.org/chromium/build/scripts/slave/compile.py?rcl=0&l=660 The odd thing is that our dbg bot gets this failing so often while the Chromium bot with exactly the same config is rock solid: https://build.chromium.org/p/chromium.win/builders/Win%20x64%20Builder%20%28dbg%29?numbuilds=200 scottmg: since you seem to have added this feature, is this something you can help us debug?
,
Jun 14 2016
I think this is being looked into in bug 586967 . |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by kjellander@chromium.org
, Jun 13 2016Labels: OS-Windows Pri-1 Type-Bug-Regression
Summary: Windows builders fail at end of compile step (goma related?) (was: buildbot failure in Chromium WebRTC FYI on Win x64 GN (dbg))