It seems to be working for me fine. Are you able to restart your machine and see if it still reproduces after a clean boot?

Tried a reboot, no change.  Tried reinstalling canary from the website, no change.  Tried deleting the Local State file, no change.

It's odd, it seems to be in some sort of loop.  When I hover my cursor over the window the cursor rapidly switches back and forth between "thinking" and "not thinking".

Thank you for providing more feedback. Adding requester "dtapuska@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

scottmg@ can you help triage this Canary crash?

Investigating.

Yup, I can repro locally on Win 7 62.0.3175.2 x86.

Unfortunately I cannot reproduce in Win 10. There was change made in color rendering pipeline which already exist in M61 as well. 

Would you mind disabling the "Color correct rendering" from chrome://flags if possible?

This is win7-only.

doesn't seem to repro with chromium @ 491831, or 491579, or 491604, which i think should correspond to 62.0.3175.2.

but after trying that, reconfirmed that still happens with canary.

i'm testing on vmware to get win7, and it looks like some sort of missing tiles or something, as some are grey, not black (the 4 corners). maybe swiftshader or something since i think that's chrome-only still (?)

re #c8, it's not possible to get to about:flags because no renderers render, but i tried --disable-color-correct-rendering and no change. (I'm not 100% sure if that's the right command line flag or not)

Got ProcExp installed, and the "changing to wait cursor and back" is because the --type=gpu-process is repeatedly trying to spawn and either crashing or exiting.

no crash dumps from crashpad or wer locally though. maybe it's just the gpu-information-getting-process.

Adding Swiftshader,Color correct rendering OWNERS for any inputs. 

+GPU experts

Latest canary-62.0.3175.2 with WIN 7 is working fine in one of my colleagues system.

Note: This is blocking our DEV RC cut scheduled at 5.00 PM PST.

--disable-gpu makes it launch ok, so likely not swiftshader, but rather another gpu problem.

(I suspect a lot of gpu people might be at SIGGRAPH atm :)

Very quick rip through https://chromium.googlesource.com/chromium/src/+log/62.0.3174.0..62.0.3175.0?pretty=fuller&n=10000 for possibilities:

https://chromium.googlesource.com/chromium/src/+/293a6765dd36405b98ce9b0ccf0f313d23f81b21

https://chromium.googlesource.com/chromium/src/+/6782ba2e36250c105b86654487e3827155afc8b1

https://chromium.googlesource.com/chromium/src/+/da036ca365910d2eda06f870a70086e7966f2ea7

https://chromium.googlesource.com/chromium/src/+/e2c169757c7cefab9081da1c332d8886621ea4b2

https://chromium.googlesource.com/chromium/src/+/6dcf39e8e0a960d29204d4e29d763049d8670ca0

https://chromium.googlesource.com/chromium/src/+/a1ea2b7987ba6d8f9cb481c13cbe85b82e32df75

Scott, do you have the clang version?

Google Chrome	62.0.3175.2 (Official Build) canary (64-bit) (cohort: Clang-64)

Yes, clang, but 32 bit. Doesn't really feel like a clang thing, but who knows I guess.

Oh, it happens on 3174.2 too. I probably should have checked that first. I wish it were easier to install through old Canaries.

Unable to reproduce this issue on Win7/64 bit - Version 62.0.3175.2 (Official Build) canary (64-bit) with Chrome Flag "Color correct rendering" set to both Enabled & Default.

OK, confirmed that 62.0.3173.2 is OK on this config, and 62.0.3174.2 is where it regressed (and 3175.2 is still bad).

I'll have a look through that changelog.

Angle roll: https://chromium.googlesource.com/angle/angle.git/+log/40ac783..5788d24

Some gpu service changes: https://chromium-review.googlesource.com/c/590773

Neither seems obviously like the problem though.

I'll see if I can figure out the individual revision bisect script again I guess.

Some recent angle roll got reverted for breaking some tests on win7 bots. So maybe it's the angle roll and we just need to merge the revert?

On second thought that might have been win7 dbg only, so probably best to ignore me

It doesn't happen with "bisect_builds.py -a win64 -g 490803 -b 491592 -o".

I thought maybe it was x86 vs x64 as a result (because there's no "-a win" archive), but I just tried 62.0.3175.2 x64 Canary and it happens there too.

Doesn't happen with a local build at head on that machine either. what the what

aha!

Broken canary with --enable-logging looks promising:


[0803/165625.596:ERROR:gl_surface_egl.cc(744)] eglInitialize D3D11 failed with error EGL_NOT_INITIALIZED, trying next display
 type
[0803/165625.903:ERROR:angle_platform_impl.cc(46)] ensureInitialized(141): D3D compiler module not found.
[0803/165625.909:ERROR:gles2_cmd_decoder.cc(9674)] [.DisplayCompositor-054087E8]GL ERROR :GL_INVALID_OPERATION : glUseProgram: progr
am not linked
[0803/165625.937:ERROR:gles2_cmd_decoder.cc(9015)] [.DisplayCompositor-054087E8]GL ERROR :GL_INVALID_OPERATION : glUniform1i: no pro
gram in use
[0803/165625.941:ERROR:gles2_cmd_decoder.cc(9015)] [.DisplayCompositor-054087E8]GL ERROR :GL_INVALID_OPERATION : glUniform4fv: no pr
ogram in use
[0803/165625.943:ERROR:gles2_cmd_decoder.cc(9015)] [.DisplayCompositor-054087E8]GL ERROR :GL_INVALID_OPERATION : glUniform1fv: no pr
ogram in use
[0803/165625.945:ERROR:gles2_cmd_decoder.cc(9015)] [.DisplayCompositor-054087E8]GL ERROR :GL_INVALID_OPERATION : glUniform2fv: no pr
ogram in use
[0803/165625.947:ERROR:gles2_cmd_decoder.cc(9015)] [.DisplayCompositor-054087E8]GL ERROR :GL_INVALID_OPERATION : glUniformMatrix4fv:
 no program in use
[0803/165625.968:ERROR:gles2_cmd_decoder.cc(9897)] [.DisplayCompositor-054087E8]RENDER WARNING: Drawing with no current shader progr
am.
[0803/165625.970:ERROR:gles2_cmd_decoder.cc(9015)] [.DisplayCompositor-054087E8]GL ERROR :GL_INVALID_OPERATION : glUniform1i: no pro
gram in use


I don't see a d3dcompiler_47.dll in the canary dir.

This could also explain why it's canary only.

Yes, that's it. Adding d3dcompiler_47.dll to the canary version dir fixes, and removing breaks it again. Now for another troll through the changelog....

And, confirmed that d3dcompiler_47.dll went missing between 62.0.3173.2 and 62.0.3174.2 official packages.

Maybe, um, grt knows about some packaging changes? I don't see anything recent in chromium src.git that'd cause this, so it feels it must be something in one of our more obscure places.

So,

https://uberchromegw.corp.google.com/i/official.desktop/builders/win64-clang/builds/383

in official_upload has d3dcompiler_47.dll (that's 3173.2)

https://uberchromegw.corp.google.com/i/official.desktop/builders/win64-clang/builds/384 (that's 3174.2)

does not and blithely says

"WARNING: File not found: D3DCompiler_47.dll"

and carries on as if all is well.

Iirc there's a ugly hack into the official build scripts to ignore the missing files for the Clang builds (because back in the days it was fine, the Syzygy files were missing and it was the easiest way to fix this). I'll take a look tomorrow.

That doesn't explain why this dll was missing, but I've seen this several time in the past. This dll was missing on all the Win builders today, see 752009.

Thanks Seb. I don't know why it went missing either, but having the build fail would definitely be better.

I'll try to see if I can figure out why it's disappearing in the morning.

https://chromium-review.googlesource.com/c/598091 did something with dlls and installers recently. Don't know if it's in the range.

And  bug 741603  us about files sometimes too (but I don't know if the script mentioned in that bug is used for packing up official builds).

https://chromium-review.googlesource.com/c/598091 did look like a good suspect but isn't in the range, first landed in 62.0.3176.0.

https://chromium-review.googlesource.com/c/598091 fixed generation of the manifest file for component builds. It shouldn't have any impact on what ends up in the version directory. (Note the use of "shouldn't" there. ;-) )

I'm stumped. The build logs show that the dll is being copied:

good: https://uberchromegw.corp.google.com/i/official.desktop/builders/win-clang/builds/384/steps/compile/logs/stdio

bad: https://uberchromegw.corp.google.com/i/official.desktop/builders/win-clang/builds/385/steps/compile/logs/stdio

But it isn't in the archive. Nothing stands out in the .gn file diffs between the two versions. Nothing at all changed in the way the mini_installer is built. It's copied from the same version of the win sdk.

This is crazy, but could something have changed such that the file is now being copied into the wrong place?

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/chrome/tools/release/scripts/+/55ad4b34df6b9be1a5bc7b73c2623f40b360a1db

commit 55ad4b34df6b9be1a5bc7b73c2623f40b360a1db
Author: Sebastien Marchand <sebmarchand@chromium.org>
Date: Fri Aug 04 15:11:19 2017

It seems like it's the same as the other magically missing files we're seeing in other bugs:

Looking at https://uberchromegw.corp.google.com/i/official.desktop/builders/win64-clang/builds/:

383 and earlier were fine
384, 385, 386 it's missing
387 it magically returned, and it's there for 388 and 389 (which is the most recent)

386 was 62.0.3175.2
387 was 62.0.3175.3

I'm not sure how to see if anything changed there, but I'm going to guess it was insignificant as far as whether that dll was included.

So this seems the same as  crbug.com/741603 .

I guess based on Seb's change to make this a fatal failure above, we can deblock Dev -- if the build succeeds then d3dcompiler will have been there even if we don't yet know why it disappears sometimes.

Working and failing builds have been mixed amongst both win-8-m0 and win-9-m0 so we can't blame a particular machine.

This is being tracked on crbug.com/752009 now, marking this one as a duplicate.