Followup. Took a closer look, and the ToTWinCFI64 buildbot appears to have been something else.

That said, doing a local ThinLTO build results in the same flatc runtime exception here with any symbol level other than 2. ?? I stumbled upon the issue because I typically build locally without debug symbols, then noted the ToTWinCFI64 buildbot is failing with the same flatc runtime exception error.

Looks to have started around here:

https://ci.chromium.org/buildbot/chromium.clang/ToTWinCFI64/590

The issue is out of TE-scope as it seems to be related to buildbot. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

Thanks!

The ToTWinThinLTO64 buildbot is currently disconnected, so I just did a local build to verify there, too.

Local build with 'use_thin_lto = true' is now returning the flatc.exe error regardless of symbol level.

C:\depot_tools\chromium\src>ninja -C out/testing flatc.exe
ninja: Entering directory `out/testing'
[21/21] LINK flatc.exe flatc.exe.pdb

C:\depot_tools\chromium\src>ninja -C out/testing extensions/browser/api/declarative_net_request/flat:extension_ruleset_gen
ninja: Entering directory `out/testing'
[2/3] ACTION //extensions/browser/api/declarative_net_requ...extension_ruleset_gen(//build/toolchain/win:win_clang_x64)
FAILED: gen/extensions/browser/api/declarative_net_request/flat/extension_ruleset_generated.h
C:/depot_tools/win_tools-2_7_6_bin/python/bin/python.exe ../../build/gn_run_binary.py flatc.exe -c --keep-prefix -o gen/extensions/browser/api/declarative_net_request/flat -I ../../ ../../extensions/browser/api/declarative_net_request/flat/extension_ruleset.fbs
flatc.exe failed with exit code 0xC0000409
ninja: build stopped: subcommand failed.

Now confirmed via the ToTWinThinLTO64 buildbot, too.

https://ci.chromium.org/buildbot/chromium.clang/ToTWinThinLTO64/839

According to https://msdn.microsoft.com/en-us/library/cc704588.aspx, 0xC0000409 is STATUS_STACK_BUFFER_OVERRUN. I can take a look at this.

Bisected to crrev.com/c/941904 (Pass /guard:cf,nolongjmp to lld now that it has some support for it.), which makes me suspect it's a bug in flatc that we're catching with control flow guard.

Sorry, not "bug in flatc" per se, but a problem in the flatc.exe we build.

use_cfi_diag = true is the setting that seems to make the difference here; if I change that to false, the build succeeds.

It's not CFI that is the actual problem here. One of the side effects of use_cfi_diag is that it sets use_rtti to true. If I do that explicitly, I can set all the CFI settings to false and I get the error when I have use_thinlto = true (with use_rtti and without use_thinlto, the build succeeds).

Filed https://bugs.llvm.org/show_bug.cgi?id=36624 to track this on the LLVM side.

To unbreak the build in the meantime, I've put up https://crrev.com/c/952666 as a suggested workaround.

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

commit 97d1b87c143adf416220c3bdf36650c8831cb6c2
Author: inglorion <inglorion@chromium.org>
Date: Wed Mar 07 23:59:00 2018

Disable /guard:cf,nolongjmp in ThinLTO configurations where it breaks.

 crbug.com/818086  shows that using control flow guard, ThinLTO, and
RTTI together results in broken binaries. This change disables CFG
when ThinLTO and RTTI are enabled to allow builds to succeed while a
fix for the problem is developed.

R=dpranke,thakis

Bug:  818086 
Change-Id: Ia926350dc4193f3a1c87a45b36a8d5dc1dd97c08
Reviewed-on: https://chromium-review.googlesource.com/952666
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#541646}
[modify] https://crrev.com/97d1b87c143adf416220c3bdf36650c8831cb6c2/build/config/win/BUILD.gn

This was fixed upstream in LLVM r327557. We need to roll clang, and then we can revert https://crrev.com/541646. We should probably try to roll past r327563 to pick up the -ffunction-sections / -fdata-sections in LTO optimization.

I am waiting on a full build to complete, but in the meantime, I can already confirm the earlier example I posted now builds with 97d1b87c143adf416220c3bdf36650c8831cb6c2 locally reverted and 'use_thin_lto = true' set.

C:\depot_tools\chromium\src>ninja -C out/testing flatc.exe
ninja: Entering directory `out/testing'
[55/55] LINK flatc.exe

C:\depot_tools\chromium\src>ninja -C out/testing extensions/browser/api/declarative_net_request/flat:extension_ruleset_gen
ninja: Entering directory `out/testing'
[3/3] STAMP obj/extensions/browser/api/declarative_net_request/flat/extension_ruleset_gen.stamp

LLVM version:

C:\src_builds\llvm-project\llvm-build\Release\bin>clang --version
clang version 7.0.0 (trunk 327681)
Target: x86_64-pc-windows-msvc

Browser build with 97d1b87c143adf416220c3bdf36650c8831cb6c2 locally reverted and 'use_thin_lto = true' set was successful.

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

commit 9ea7ffa8290370361c8d2bde8e13b5adac66acc7
Author: inglorion <inglorion@chromium.org>
Date: Fri Apr 06 03:40:21 2018

Revert "Disable /guard:cf,nolongjmp in ThinLTO configurations where it breaks."

This reverts crrev.com/c/952666. That commit was a workaround for a
bug which was fixed in Clang r327557, so the workaround is no longer
needed.

R=depranke,brucedawson

Bug:  818086 
Change-Id: I98ba3cea051734da2eef81fe1986c9f9b5d9b617
Reviewed-on: https://chromium-review.googlesource.com/998513
Reviewed-by: Bruce Dawson <brucedawson@chromium.org>
Reviewed-by: Dirk Pranke <dpranke@chromium.org>
Commit-Queue: Bob Haarman <inglorion@chromium.org>
Cr-Commit-Position: refs/heads/master@{#548657}
[modify] https://crrev.com/9ea7ffa8290370361c8d2bde8e13b5adac66acc7/build/config/win/BUILD.gn

Verified that ToTWinCFI64 is green after reverting the workaround.