New issue
Advanced search Search tips

Issue 617434 link

Starred by 1 user
Status: Duplicate
Merged: issue 611319
Owner:
blundell@chromium.org
Closed: Jun 2016
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug



Sign in to add a comment

Possible ordering issue generating kasko_features.h

Project Member Reported by sh...@chromium.org, Jun 5 2016 
https://build.chromium.org/p/chromium/builders/Win/builds/44040/steps/compile/logs/stdio

[5167/33845] CXX obj\chrome\installer\setup\setup_lib.installer_crash_reporting.obj
FAILED: obj/chrome/installer/setup/setup_lib.installer_crash_reporting.obj 
ninja -t msvc -e environment.x86 -- C:\b\build\slave\cache\cipd\goma/gomacc "C:\b\depot_tools\win_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97\VC\bin\amd64_x86\cl.exe" /nologo /showIncludes /FC @obj\chrome\installer\setup\setup_lib.installer_crash_reporting.obj.rsp /c ..\..\chrome\installer\setup\installer_crash_reporting.cc /Foobj\chrome\installer\setup\setup_lib.installer_crash_reporting.obj /Fdobj\chrome\setup_lib.cc.pdb 
c:\b\build\slave\win\build\src\components\crash\content\app\crashpad.h(15): fatal error C1083: Cannot open include file: 'third_party/kasko/kasko_features.h': No such file or directory

AFAICT, neither crashpad.h nor third_party/kasko has changed in months.

I suspect https://codereview.chromium.org/2038473002/ , but I'm not entirely sure I have time to debug things this evening.

Comment 1 by sdefresne@chromium.org, Jun 5 2016 

As far as I can tell, the cl you point as the possible cause is fixing one such issue by explicitly declaring a missing dependency and thus fixing an ordering bug. My guess is that there are other missing dependencies that the change revealed.

In general if you have a target generating an header file and another target using it, you need to have a public dependency (public_deps in gn, export_all_dependent_settings in gyp) otherwise you have a flaky build.

Comment 2 by sh...@chromium.org, Jun 5 2016 

It feels like a problem where incremental builds worked because the header file was in place, but something initiated a clobber build and the file wasn't in place

BUT, chrome-cron later forced a build with a VERSION change, and it was clean.  So I'm going to open things.  Maybe this is a red herring?  Maybe build systems are subtle and quick to anger?

Comment 3 by sdefresne@chromium.org, Jun 6 2016 

What I tried to say in my previous comment is that incremental builds will most likely succeed even if there are missing dependencies but they may cause random failures after a clobber build.

So, we should track those missing dependencies and fix them. The CL by blundell@ did fix one such missing dependency, but it is probably only one in many.

Comment 4 by blundell@chromium.org, Jun 6 2016

Mergedinto: 611319
Status: Duplicate (was: Unconfirmed)
This issue is  crbug.com/611319 . That CL was an attempt to fix the flaky dependency problem, but it looks like it didn't get the job done. The CL is not the *cause* of the flaky dependency problem, though.

Comment 5 by sh...@chromium.org, Jun 6 2016 

Looks like builds have been clean since I re-opened, so I guess flaky sounds right.

Apologies for not searching for a bug.  It honestly didn't even occur to me :-).
►

Sign in to add a comment