The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/0da17134e2f492e7593ca6e62b554125fb923df7

commit 0da17134e2f492e7593ca6e62b554125fb923df7
Author: machenbach <machenbach@chromium.org>
Date: Wed Apr 13 16:51:04 2016

[build] Port latest vs_toolchain script.

BUG= chromium:603011 , chromium:603131 
LOG=n

Review URL: https://codereview.chromium.org/1880383003

Cr-Commit-Position: refs/heads/master@{#35452}

[modify] https://crrev.com/0da17134e2f492e7593ca6e62b554125fb923df7/build/vs_toolchain.py

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/8f8dd7150f39f9067f4f7493a32931b296e6d9b6

commit 8f8dd7150f39f9067f4f7493a32931b296e6d9b6
Author: machenbach <machenbach@chromium.org>
Date: Thu Apr 14 07:58:21 2016

[build] New VS 2013 toolchain with setenv.*.json

Port https://codereview.chromium.org/1886493002

BUG= chromium:603011 ,  chromium:603131 
LOG=n
TBR=jochen@chromium.org

Review URL: https://codereview.chromium.org/1880423003

Cr-Commit-Position: refs/heads/master@{#35470}

[modify] https://crrev.com/8f8dd7150f39f9067f4f7493a32931b296e6d9b6/build/vs_toolchain.py

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/e51e8b4ad77008ec7f88c144853e01001dbea900

commit e51e8b4ad77008ec7f88c144853e01001dbea900
Author: machenbach <machenbach@chromium.org>
Date: Thu Apr 14 11:39:24 2016

[build] Use MSVS 2015 by default.

BUG= chromium:603131 
LOG=y

Review URL: https://codereview.chromium.org/1886983002

Cr-Commit-Position: refs/heads/master@{#35487}

[modify] https://crrev.com/e51e8b4ad77008ec7f88c144853e01001dbea900/build/config/win/msvs_dependencies.isolate
[modify] https://crrev.com/e51e8b4ad77008ec7f88c144853e01001dbea900/build/get_landmines.py
[modify] https://crrev.com/e51e8b4ad77008ec7f88c144853e01001dbea900/build/isolate.gypi
[modify] https://crrev.com/e51e8b4ad77008ec7f88c144853e01001dbea900/build/standalone.gypi
[modify] https://crrev.com/e51e8b4ad77008ec7f88c144853e01001dbea900/build/vs_toolchain.py

 Issue v8:4326  has been merged into this issue.

Win debug got very crashy after the switch, e.g.:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug/builds/1639
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/9161
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20debug/builds/9164

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/290ee88f63a3b94d87483dbd71ab9f581349ddc6

commit 290ee88f63a3b94d87483dbd71ab9f581349ddc6
Author: machenbach <machenbach@chromium.org>
Date: Thu Apr 14 14:53:07 2016

Revert of [build] Use MSVS 2015 by default. (patchset #4 id:60001 of https://codereview.chromium.org/1886983002/ )

Reason for revert:
Introduced flaky crashes on win debug.

Original issue's description:
> [build] Use MSVS 2015 by default.
>
> BUG= chromium:603131 
> LOG=y
>
> Committed: https://crrev.com/e51e8b4ad77008ec7f88c144853e01001dbea900
> Cr-Commit-Position: refs/heads/master@{#35487}

TBR=jochen@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= chromium:603131 

Review URL: https://codereview.chromium.org/1890873002

Cr-Commit-Position: refs/heads/master@{#35498}

[modify] https://crrev.com/290ee88f63a3b94d87483dbd71ab9f581349ddc6/build/config/win/msvs_dependencies.isolate
[modify] https://crrev.com/290ee88f63a3b94d87483dbd71ab9f581349ddc6/build/get_landmines.py
[modify] https://crrev.com/290ee88f63a3b94d87483dbd71ab9f581349ddc6/build/isolate.gypi
[modify] https://crrev.com/290ee88f63a3b94d87483dbd71ab9f581349ddc6/build/standalone.gypi
[modify] https://crrev.com/290ee88f63a3b94d87483dbd71ab9f581349ddc6/build/vs_toolchain.py

Any idea what might make v8 more crashy with msvs 2015? Nearly all of the crashes are tests expected to fail, and there's this error code detection for crashes in our driver:
https://code.google.com/p/chromium/codesearch#chromium/src/v8/tools/testrunner/objects/output.py&l=44

I couldn't repro any of the crashes yet. I wonder if the error codes can be different after the switch but still indicating just a failure and not a crash and we're interpreting it wrong now?

The bit mask for the crash detection goes back to:
https://codereview.chromium.org/8676

There was a behavioral change in BoringSSL's thread local destructors that caused (I don't remember details, maybe look at crbug.com/595795) the return code of a child thread to be used as the process exit code. This was indirectly related to the VS 2015 switch.

Sorry for the hand waving, but it's possible that your error code detection is being messed up by other threads in the system. I guess you'll need to see if you have actual new crashes, or just failures that are being interpreted as crashes, and then investigate as appropriate.

Let me know what you find out.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/build.git/+/4758d88c4acaa04f72b789372074c1ace13fb05c

commit 4758d88c4acaa04f72b789372074c1ace13fb05c
Author: machenbach@chromium.org <machenbach@chromium.org>
Date: Fri Apr 15 12:12:46 2016

V8: Add mozilla test to win dbg.

BUG= 603131 
TBR=tandrii@chromium.org

Review URL: https://codereview.chromium.org/1890093002

git-svn-id: svn://svn.chromium.org/chrome/trunk/tools/build@299956 0039d316-1c4b-4281-b951-d872f2087c98

[modify] https://crrev.com/4758d88c4acaa04f72b789372074c1ace13fb05c/scripts/slave/recipe_modules/v8/builders.py
[modify] https://crrev.com/4758d88c4acaa04f72b789372074c1ace13fb05c/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win64_dbg.json
[modify] https://crrev.com/4758d88c4acaa04f72b789372074c1ace13fb05c/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win_dbg.json

FYI: The crashes we were seeing had all return code -1073741819 = 0xc0000005 = ACCESS_VIOLATION, according to ntstatus.h.

Our framework detects it correctly as crash with the line:
0x80000000 & self.exit_code and not (0x3FFFFF00 & self.exit_code)

It happens only in test cases that are supposed to fail, e.g. with a JS exception. So maybe we now trigger a path in our shutdown routines that leads to this new crash.

Theory from mvstanton (correct me if I'm wrong): It looks like something deletes a critical section despite a thread waiting for it. When the waiting thread tries to acquire a lock it crashes.

I caught this once in the debugger without symbols :/ but with some extra OS checks turned on. Log of the session:
https://paste.googleplex.com/5499735922180096

I also caught it once with symbols but without the extra OS checks. Log of the session:
https://paste.googleplex.com/4726538192814080

I'm still trying to catch it using a build with symbols and extra OS checks on. I'll ping here if that happens. Any more advice is very welcome.

FYI: In this session we caught it with application verifier turned on:
https://paste.googleplex.com/6072595220791296

A critical section is deleted through the code in v8::Shell::exit. The code originates from here:
https://chromium.googlesource.com/v8/v8/+/8330176f3f81117e198a698c94bf21c798258d06

FYI: Still seeing the crashes when using exit instead of _exit:
https://codereview.chromium.org/1886983002/#ps100001

@brucedawson or scottmg or any other windows expert:
I'll try to summarize where we stand and what we're blocked on. The above analysis makes it look like our problem is similar to the one from  https://bugs.chromium.org/p/boringssl/issues/detail?id=45 . But nobody knows for sure yet.

What we know:
1. A critical section is deleted by the system's exit function with a lock count off by one.
2. The section is entered shortly after
3. We're shutting down d8-standalone and don't really care. We already know a script execution went wrong. We just wanna get out of there...

Suggestions:
A: We could implement one of the suggested solutions in the boringssl bug (shot in the dark + I'm not sure were to begin in our code base).
B: More pragmatic: We could try to suppress the crash on shut down. We know it's coming, we don't care.

You can assign the bug to me if you want, since I'm a Windows nerd and the VS 2015 migration person.

Passing the buck to Bruce, since I've not much time right now to look into this. PTAL

Bruce, did you have any chance to look into this? I'd like to start using some language features that require MSVC 2015 but can't until we move the bots to it. Is there anything I can do to help?

I can also try if anything changed after the gn switch of our bots. For this I need to disentangle the hard-coded MSVS2013 configs on the infra side (in order to make a try-CL on the V8 side).

FYI: This is still happening after the gn switch - exemplifying CL:
https://codereview.chromium.org/2359093002

See trybot flakes:
https://build.chromium.org/p/tryserver.v8/builders/v8_win64_dbg/builds/381
https://build.chromium.org/p/tryserver.v8/builders/v8_win_dbg/builds/406

Apologies for not looking into this yet. It's a combination of being busy and not being sure what to do about this bug. I'm not surprised that the gn switch didn't help.

Probably not next week, but maybe the week after? Again, sorry about the delay.

np

Okay, I understand this and I have a possible solution. I'll excessively document everything here.

I did a build with these settings:

is_component_build = false
is_debug = true
target_cpu = "x64"
is_clang = false
v8_enable_backtrace = true
v8_enable_slow_dchecks = true
v8_test_isolation_mode = "prepare"

and then ran this batch file for many hours:

:start
"c:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe" -g -G out\debug\d8.exe --test --nocrankshaft --random-seed=-440401462 --nohard-abort --nodead-code-elimination --nofold-constants --enable-slow-asserts --debug-code --verify-heap --expose-gc test\mozilla\mozilla-shell-emulation.js test\mozilla\data\shell.js test\mozilla\data\ecma\shell.js test\mozilla\data\ecma\LexicalConventions\shell.js test\mozilla\data\ecma\LexicalConventions\7.5-8-n.js
goto start

and I eventually hit the crash, which I have saved. The crashing call stack is shown here:

 	ntdll.dll!RtlpWaitOnCriticalSection()	Unknown
 	ntdll.dll!RtlpEnterCriticalSectionContended()	Unknown
 	ntdll.dll!RtlEnterCriticalSection()	Unknown
 	d8.exe!__acrt_lock(__acrt_lock_id _Lock) Line 55	C++
>	d8.exe!_free_dbg(void * block, int block_use) Line 1000	C++
 	d8.exe!__crt_internal_free_policy::operator()<__acrt_ptd>(const __acrt_ptd * const p) Line 314	C++
 	d8.exe!__crt_unique_heap_ptr<__acrt_ptd,__crt_internal_free_policy>::release() Line 371	C++
 	d8.exe!__crt_unique_heap_ptr<__acrt_ptd,__crt_internal_free_policy>::~__crt_unique_heap_ptr<__acrt_ptd,__crt_internal_free_policy>() Line 345	C++
 	d8.exe!internal_get_ptd_head() Line 231	C++
 	d8.exe!internal_getptd_noexit() Line 246	C++
 	d8.exe!__acrt_getptd() Line 262	C++
 	d8.exe!thread_start<unsigned int (__cdecl*)(void * __ptr64)>(void * const parameter) Line 104	C++
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

So, a background thread is doing some work and it tries to free some memory only to find that the critical section used by the CRT to protect the heap has been deleted.

Meanwhile the main thread is in this call stack:

 	kernel.appcore.dll!PsmpCloseContext()	Unknown
 	kernel.appcore.dll!DllMain()	Unknown
 	ntdll.dll!LdrpCallInitRoutine()	Unknown
 	ntdll.dll!LdrpProcessDetachNode()	Unknown
 	ntdll.dll!LdrpUnloadNode()	Unknown
 	ntdll.dll!LdrpDecrementModuleLoadCount()	Unknown
 	ntdll.dll!LdrUnloadDll()	Unknown
 	KERNELBASE.dll!FreeLibrary()	Unknown
>	d8.exe!__acrt_uninitialize_winapi_thunks(bool terminating) Line 185	C++
 	d8.exe!__acrt_execute_uninitializers(const __acrt_initializer * first, const __acrt_initializer * last) Line 64	C++
 	d8.exe!__acrt_uninitialize(bool terminating) Line 282	C++
 	d8.exe!__scrt_uninitialize_crt(bool is_terminating, bool from_exit) Line 221	C++
 	d8.exe!common_exit(const int return_code, const _crt_exit_cleanup_mode cleanup_mode, const _crt_exit_return_mode return_mode) Line 267	C++
 	d8.exe!_Exit(int return_code) Line 293	C++
 	d8.exe!v8::Shell::Exit(int exit_code) Line 1578	C++
 	d8.exe!v8::SourceGroup::Execute(v8::Isolate * isolate) Line 1954	C++
 	d8.exe!v8::Shell::RunMain(v8::Isolate * isolate, int argc, char * * argv, bool last_run) Line 2445	C++
 	d8.exe!v8::Shell::Main(int argc, char * * argv) Line 2925	C++
 	d8.exe!invoke_main() Line 65	C++
 	d8.exe!__scrt_common_main_seh() Line 253	C++
 	d8.exe!__scrt_common_main() Line 296	C++
 	d8.exe!mainCRTStartup() Line 17	C++
 	kernel32.dll!BaseThreadInitThunk()	Unknown
 	ntdll.dll!RtlUserThreadStart()	Unknown

So, the bug is that we are calling _exit (shown in the call stack as d8.exe!_Exit) while an unknown number of threads are doing potentially arbitrary work. While calling _exit() instead of exit() (thus avoiding the running of global-object destructors) may reduce the scope of this race condition, the race condition remains. The CRT tries to shut itself down, but the other threads are still using it. This cannot be made safe.

The "ideal" solution would be to cleanly shut down all worker threads, but this is presumably and reasonably untenable.
The only other "solution" is to call TerminateProcess (https://msdn.microsoft.com/en-us/library/windows/desktop/ms686714(v=vs.85).aspx). Specifically:
    TerminateProcess(GetCurrentProcess(), exit_code);

This is ugly but effective and (unless we can cleanly shut down all threads) necessary. The fact that we weren't hitting this crash with VS 2013 is purely luck.

Here are some scary reads about process shutdown - don't read before bed if you're scared of monsters:

https://blogs.msdn.microsoft.com/oldnewthing/20070503-00/?p=27003
https://blogs.msdn.microsoft.com/oldnewthing/20100122-00/?p=15193

I don't know if this problem is the same one that boringssl is hitting.

Thanks Bruce for the great analysis and for the work getting there!

I assume a V8 dev could take over from here and implement using the TerminateProcess method.

yangguo or mvstanton: Could you find an owner for this?

Thanks Bruce for the research! I'll implement this.

Awesome! Then you also get the bug :)

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/639f6f1774cd73d392284fa090ce012aebcaa363

commit 639f6f1774cd73d392284fa090ce012aebcaa363
Author: yangguo <yangguo@chromium.org>
Date: Mon Nov 07 07:24:48 2016

[d8] cleanly force exit in d8 on windows.

Using _exit on windows may cause race conditions in threads.

BUG= chromium:603131 

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

[modify] https://crrev.com/639f6f1774cd73d392284fa090ce012aebcaa363/src/d8-posix.cc
[modify] https://crrev.com/639f6f1774cd73d392284fa090ce012aebcaa363/src/d8-windows.cc
[modify] https://crrev.com/639f6f1774cd73d392284fa090ce012aebcaa363/src/d8.cc

Fix to d8 has landed. Michael, anything left to do?

doesn't cctests have the same issue?

also wondering: can't we just cleanup our threads in d8? in cctests, it's probably not worthwhile, but d8 only has a bunch of dedicated workers and the background worker pool running..

I'll attempt to make the switch again. In the meantime something else broke and my old CL doesn't work anymore. Will have a look.

> doesn't cctests have the same issue?

Quite possibly, I don't know.

> can't we just cleanup our threads in d8?

That would be another way of making this work, if it is practical. However my assumption was that when an unexpected error occurred we might be in an unexpected state, and that shutting down the worker threads could therefore be impractical.

Also, unless we have some reason why we need/want our global destructors to run, TerminateProcess is totally reasonable. We even have a bug open (crbug.com/490716) which suggests using TerminateProcess on renderer processes because it is faster than in-process cleanup (much faster if some of the memory that needs freeing has been paged out).

I think in cctests we would either complete the test normally, or encounter a CHECK failure, in which case the OS would kill the process via signal. I don't think we have an explicit quit somewhere in cctests.

Great to see progress here!
How did your switch attempt go, Michael?

I am currently having issues with an internal compiler bug in VS13 on variadic templates, and broken support for SFINAE.

Stuck again. Independent of the fix we now get exit code:
-1073741515 == 0xC0000135 == STATUS_DLL_NOT_FOUND

Also in the CL that I used earlier to switch on MSVS2015:
https://codereview.chromium.org/2359093002/

A while back it ran the tests and only once in a while triggered the bug that's now supposed to be fixed.

Now, the same CL without any change runs into this new error.

Also tried to revert the current fix to make sure it's independent of that:
https://codereview.chromium.org/2529363002

What changed in the meantime? Anything in the toolchain? Do we need to set any extra gn args to address the sdk correctly?

To make sure it's src/build independent I created a CL using the same old src/build revision that the last green try attempts used:
https://codereview.chromium.org/2532903002/

It also fails. So, is it maybe depot_tools dependent? Or did the swarming windows VMs change in the meantime regarding SDK?

Different way of switching to 2015:
https://codereview.chromium.org/2533813002

Same problem. Just wanted to make sure it's not our local vs_toolchain script.

Of cause any other change that landed in V8 since I tried to switch last time might play a role here as the trybot always uses current HEAD. Maybe I trigger a few older revisions if possible.

Interesting. With the original V8 revision it passes. So I'll start bisecting.

Just 1694 commits :/

And the winner is: me :)

Bisect points to when we enabled shared library builds:
https://chromium.googlesource.com/v8/v8/+/f72b4a084af3

jgruber, could you take a look? You can apply https://codereview.chromium.org/2533813002/ to switch to MSVS2015. With component_build and is_debug the unittests executable returns error code -1073741515 == 0xC0000135 == STATUS_DLL_NOT_FOUND when listing the tests.

Question for everybody: Do we need to add some extra configuration for pointing to the right MSVS2015 dlls? Is this maybe only on swarming and lacks isolating a dll?

TODO: After this is resolved https://crrev.com/f89b499961b139f38e8e01282a82d4ba5d21506e can be reverted.

Thanks jgruber for analysis. Local error:
error while loading shared libraries: ucrtbased.dll: cannot open shared object file: No such file or directory

Looks like we might need to add back the msvs dependencies file:
https://cs.chromium.org/chromium/src/base/base.isolate?q=msvs_dependencies.isolate&sq=package:chromium&l=13&dr=C

I thought the isolate driver finds all these dynamically, but maybe I was wrong or our fork of the driver is out-dated.

we copy the dlls via gn in chromium: https://cs.chromium.org/search/?q=file:%5C.gn+runtime.dll&sq=package:chromium&type=cs mb then creates an isolate with that. Maybe you're not using mb?

V8 uses MB but not to create isolates. We still use a legacy approach. Filed 669910 to change that, but in the mean time I'll still work on switching to MSVS2015 with the legacy deps files. The current WIP CL looks promising and has the first green bot:
https://codereview.chromium.org/2533813002/

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/6b9c49cac101d1a373ae1a098b7959f8aff848ac

commit 6b9c49cac101d1a373ae1a098b7959f8aff848ac
Author: machenbach <machenbach@chromium.org>
Date: Thu Dec 01 08:16:18 2016

[build] Use MSVS 2015 by default.

BUG= chromium:603131 
LOG=y

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

[modify] https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac/DEPS
[modify] https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac/gni/isolate.gni
[add] https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac/gypfiles/win/msvs_dependencies.isolate
[modify] https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac/src/base.isolate
[modify] https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac/tools/mb/mb.py

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/48a522b6434907fd6db0a7a1a13333d53d386bea

commit 48a522b6434907fd6db0a7a1a13333d53d386bea
Author: machenbach <machenbach@chromium.org>
Date: Thu Dec 01 08:35:13 2016

Revert of [build] Use MSVS 2015 by default. (patchset #5 id:80001 of https://codereview.chromium.org/2533813002/ )

Reason for revert:
Breaks CI dbg builder:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20debug%20builder/builds/13817

Original issue's description:
> [build] Use MSVS 2015 by default.
>
> BUG= chromium:603131 
> LOG=y
>
> Committed: https://crrev.com/6b9c49cac101d1a373ae1a098b7959f8aff848ac
> Cr-Commit-Position: refs/heads/master@{#41407}

TBR=jochen@chromium.org,vogelheim@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= chromium:603131 

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

[modify] https://crrev.com/48a522b6434907fd6db0a7a1a13333d53d386bea/DEPS
[modify] https://crrev.com/48a522b6434907fd6db0a7a1a13333d53d386bea/gni/isolate.gni
[delete] https://crrev.com/2c3fe6d961e4a496bf5edc33a14c5c09245185c9/gypfiles/win/msvs_dependencies.isolate
[modify] https://crrev.com/48a522b6434907fd6db0a7a1a13333d53d386bea/src/base.isolate
[modify] https://crrev.com/48a522b6434907fd6db0a7a1a13333d53d386bea/tools/mb/mb.py

CL https://codereview.chromium.org/2533813002 has landed again and seems to stick :)

Thanks for all fixes and investigations. Will remove some CC's now for work on more infra clean up.

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

commit fd2c63b1b790d0c41a41b708271e3d0264cbdbee
Author: machenbach <machenbach@chromium.org>
Date: Fri Dec 02 15:58:34 2016

Reland of win: Remove unneeded references to visual_studio_version now that it's always 2015. (patchset #2 id:150001 of https://codereview.chromium.org/2531333004/ )

Reason for revert:
V8 is on 2015 now.

Original issue's description:
> Revert of win: Remove unneeded references to visual_studio_version now that it's always 2015. (patchset #4 id:60001 of https://codereview.chromium.org/2450933002/ )
>
> Reason for revert:
> V8 relies on this.
>
> Original issue's description:
> > win: Remove unneeded references to visual_studio_version now that it's always 2015.
> >
> > BUG=
> >
> > Committed: https://crrev.com/a628db5056deb88589224bd68dcd9ec029932c83
> > Cr-Commit-Position: refs/heads/master@{#427463}
>
> TBR=scottmg@chromium.org,thakis@chromium.org
> # Not skipping CQ checks because original CL landed more than 1 days ago.
> BUG=
>
> Committed: https://crrev.com/f89b499961b139f38e8e01282a82d4ba5d21506e
> Cr-Commit-Position: refs/heads/master@{#434945}

TBR=scottmg@chromium.org,thakis@chromium.org,brucedawson@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 603131 

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

[modify] https://crrev.com/fd2c63b1b790d0c41a41b708271e3d0264cbdbee/base/BUILD.gn
[modify] https://crrev.com/fd2c63b1b790d0c41a41b708271e3d0264cbdbee/build/config/compiler/BUILD.gn
[modify] https://crrev.com/fd2c63b1b790d0c41a41b708271e3d0264cbdbee/build/config/win/BUILD.gn
[modify] https://crrev.com/fd2c63b1b790d0c41a41b708271e3d0264cbdbee/build/config/win/visual_studio_version.gni
[modify] https://crrev.com/fd2c63b1b790d0c41a41b708271e3d0264cbdbee/chrome/installer/mini_installer/BUILD.gn

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/tools/build.git/+/e00d048a13a62a9d50704aaeed1cefaf549fcf6f

commit e00d048a13a62a9d50704aaeed1cefaf549fcf6f
Author: Michael Achenbach <machenbach@chromium.org>
Date: Mon Dec 05 10:02:00 2016

V8: Remove references to MSVS 2013 now that V8's on 2015.

BUG= 603131 

Change-Id: If2e11e6310eae70183f710a38a07e899444eb87a
Reviewed-on: https://chromium-review.googlesource.com/415889
Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>

[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipe_modules/chromium/config.py
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipe_modules/v8/api.py
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipe_modules/v8/builders.py
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_client_dart_fyi_v8_win_release.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_client_v8_V8_Win32___builder.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_client_v8_V8_Win32___debug_builder.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_client_v8_V8_Win32___nosnap___shared.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_client_v8_V8_Win64.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_client_v8_V8_Win64___debug.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win64_dbg.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win64_rel_ng.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win_compile_dbg.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win_dbg.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win_nosnap_shared_rel_ng.json
[modify] https://crrev.com/e00d048a13a62a9d50704aaeed1cefaf549fcf6f/scripts/slave/recipes/v8.expected/full_tryserver_v8_v8_win_rel_ng.json

Ping - please provide an update to your high priority bug. This bug is stale. Is it really P-1?

A few minor cleanup tasks are left.

Main blocker has been fixed. Now this is finally cleaned up (and we're on msvc 2017 by now anyways... no wait, we're on clang!).