Bisect started here:
https://chromeperf.appspot.com/buildbucket_job_status/9008330659286917184

Bisect failed, new one at:
https://chromeperf.appspot.com/buildbucket_job_status/9008316539330628432

New bisect here:
https://chromeperf.appspot.com/buildbucket_job_status/9007867493432333024

 Issue 625853  has been merged into this issue.

From https://bugs.chromium.org/p/chromium/issues/detail?id=625853#c2, petrcermak@ says:
I think that my patch is the most likely (indirect) culprit: https://codereview.chromium.org/2094143005. I suggest we speculatively revert it.

This fits with the revision range I'm seeing, eg: https://uberchromegw.corp.google.com/i/chromium.perf/builders/Win%20Zenbook%20Perf%20%283%29/builds/2026

Will speculatively revert.

Revert in progress here: https://codereview.chromium.org/2124333002/

Revert landed: https://chromium.googlesource.com/chromium/src/+/5f24850ea0b9b4b4a8573c97f11758507e22ebde

Waiting to see if the next build passes: https://build.chromium.org/p/chromium.perf/builders/Win%20Zenbook%20Perf%20%283%29/builds/2105

I can confirm that the builds are green again starting from the revert (https://build.chromium.org/p/chromium.perf/builders/Win%20Zenbook%20Perf%20%283%29/builds/2106), so I'm lowering the priority of this issue.

The failures were happening consistently on the following 4 stories:

  load:search:baidu
  load:news:bbc
  load:games:miniclip
  load:news:qq

With the following native crash (more details in
https://build.chromium.org/p/chromium.perf/builders/Win%20Zenbook%20Perf%20%283%29/builds/2105/steps/system_health.memory_desktop/logs/stdio):

  .  0  Id: 15a8.13c4 Suspend: 0 Teb: 00007ff7`3d65d000 Unfrozen
  Child-SP          RetAddr           Call Site
  00000012`ad4285a8 00007ffc`52783757 ntdll!ZwDelayExecution+0xa
  *** WARNING: Unable to verify checksum for chrome.exe
  00000012`ad4285b0 00007ff7`3dd20e60 KERNELBASE!SleepEx+0xa7
  00000012`ad428650 00007ff7`3dd1909f chrome!std::vector<crashpad::CrashReportDatabase::Report,std::allocator<crashpad::CrashReportDatabase::Report> >::_Umove<crashpad::CrashReportDatabase::Report * __ptr64>+0x100
  00000012`ad428790 00007ff7`3dd19124 chrome!CrashForException+0xc3
  00000012`ad4288d0 00007ffc`552f633d chrome!InjectDumpForHangDebugging+0x44
  00000012`ad428910 00007ffc`55273c00 ntdll!_chkstk+0xfd
  00000012`ad428940 00007ffc`552f544a ntdll!RtlWalkFrameChain+0x1560
  00000012`ad429040 00007ffc`33c61cc8 ntdll!KiUserExceptionDispatcher+0x3a
  00000012`ad429760 00007ffc`34c21e2d chrome_child!??$_Try_emplace@V?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@base@@$$V@?$map@V?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@base@@_NU?$less@V?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@base@@@std@@V?$allocator@U?$pair@$$CBV?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@base@@_N@std@@@4@@std@@QEAA?AU?$pair@V?$_Tree_iterator@V?$_Tree_val@U?$_Tree_simple_types@U?$pair@$$CBV?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@base@@_N@std@@@std@@@std@@@std@@_N@1@$$QEAV?$BasicStringPiece@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@base@@@Z+0x118
  00000012`ad429790 00007ffc`34c45490 chrome_child!_invalid_parameter_noinfo+0x19
  00000012`ad4297d0 00007ffc`34c4b6fd chrome_child!_isatty+0x58
  00000012`ad429800 00007ffc`34c22885 chrome_child!__acrt_stdio_begin_temporary_buffering_nolock+0x19
  (Inline Function) --------`-------- chrome_child!__acrt_stdio_temporary_buffering_guard::{ctor}+0x8
  00000012`ad429830 00007ffc`34c21fa6 chrome_child!<lambda_0a64b6a4deda75c01876f29c44fc5eb3>::operator()+0x35
  00000012`ad429d30 00007ffc`34c25505 chrome_child!__crt_seh_guarded_call<int>::operator()<<lambda_aa279a7bcb127014629d5b1d62c7325d>,<lambda_0a64b6a4deda75c01876f29c44fc5eb3> & __ptr64,<lambda_3323e69fbefe9d1a11713e670d47cdfa> >+0x26
  (Inline Function) --------`-------- chrome_child!__acrt_lock_stream_and_call+0x41
  (Inline Function) --------`-------- chrome_child!common_vfprintf+0x64
  00000012`ad429d60 00007ffc`343d50ca chrome_child!__stdio_common_vfprintf+0x85
  00000012`ad429dd0 00007ffc`343d514d chrome_child!WTF::TextPosition::fromOffsetAndLineEndings+0x176
  00000012`ad429e10 00007ffc`343d5190 chrome_child!WTF::TextPosition::fromOffsetAndLineEndings+0x1f9
  00000012`ad429e40 00007ffc`3336c102 chrome_child!WTFLogAlways+0x20
  00000012`ad429e70 00007ffc`3336c302 chrome_child!blink::TraceTrait<blink::FormSubmission>::trace+0x2a2
  00000012`ad429ed0 00007ffc`3336d2d4 chrome_child!blink::TraceTrait<blink::FormSubmission>::trace+0x4a2
  00000012`ad429f10 00007ffc`332637af chrome_child!blink::FrameFetchContext::resourceRequestCachePolicy+0x284
  00000012`ad429f40 00007ffc`332631c9 chrome_child!blink::ResourceFetcher::initializeResourceRequest+0x3f
  00000012`ad429f90 00007ffc`3326b781 chrome_child!blink::ResourceFetcher::requestResource+0x359
  00000012`ad42a370 00007ffc`32eabe6f chrome_child!blink::ScriptResource::fetch+0x91
  00000012`ad42a450 00007ffc`32eab5af chrome_child!blink::ScriptLoader::fetchScript+0x3ef
  00000012`ad42a8d0 00007ffc`32ffcc83 chrome_child!blink::ScriptLoader::prepareScript+0x2ff
  00000012`ad42aa90 00007ffc`32ffc23d chrome_child!blink::HTMLScriptRunner::runScript+0xc3
  00000012`ad42ac30 00007ffc`32fe63d7 chrome_child!blink::HTMLScriptRunner::execute+0xfd
  00000012`ad42acb0 00007ffc`32fe6411 chrome_child!blink::HTMLDocumentParser::runScriptsForPausedTreeBuilder+0x57
  00000012`ad42ace0 00007ffc`32fe82d8 chrome_child!blink::HTMLDocumentParser::canTakeNextToken+0x31
  00000012`ad42ad10 00007ffc`32fe8a0d chrome_child!blink::HTMLDocumentParser::pumpTokenizer+0x398
  00000012`ad42ae50 00007ffc`32e37585 chrome_child!blink::HTMLDocumentParser::insert+0x3ad
  00000012`ad42afe0 00007ffc`32e375dd chrome_child!blink::Document::write+0x2f5
  00000012`ad42b070 00007ffc`32e379d3 chrome_child!blink::Document::write+0x2d
  00000012`ad42b100 00007ffc`32be38e4 chrome_child!blink::Document::write+0x1d3
  00000012`ad42b490 00007ffc`32be39bc chrome_child!blink::XPathEvaluator::create+0x11d04
  00000012`ad42b530 00007ffc`321fa300 chrome_child!blink::XPathEvaluator::create+0x11ddc
  00000012`ad42b570 00007ffc`3228e302 chrome_child!v8::internal::FunctionCallbackArguments::Call+0x160
  00000012`ad42b650 00007ffc`32283e50 chrome_child!v8::internal::CopyChars<unsigned char,unsigned short>+0x622
  00000012`ad42b770 00007ffc`32283d4b chrome_child!v8::internal::Builtins::Generate_StringPrototypeValueOf+0x1c60
  00000012`ad42b810 00000171`b47063ab chrome_child!v8::internal::Builtins::Generate_StringPrototypeValueOf+0x1b5b
  00000012`ad42b850 00007ffc`3251cfff 0x00000171`b47063ab
  00000012`ad42b858 00000397`4dd060e1 chrome_child!v8::internal::Runtime_CallIC_Miss+0xc0f
  00000012`ad42b860 00000000`beeddead 0x00000397`4dd060e1
  00000012`ad42b868 00000012`ad624b90 <Unloaded_Unknown_Module_00000000`00000002>+0xbeeddeab

The failure always happens in the WTFLogAlways call in
emitWarningForDocWriteScripts:

  https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/loader/FrameFetchContext.cpp?rcl=1467947789&l=88

This is confirmed by the fact that every failure is preceded by the
following DevTools message (or similar):

  [3568:3488:0707/123616:INFO:CONSOLE(123)] "A Parser-blocking,
  cross-origin script,
  http://static.bbci.co.uk/frameworks/requirejs/lib.js, is invoked via
  document.write. This may be blocked by the browser if the device has
  poor network connectivity.", source:
  http://www.bbc.co.uk/news/world-asia-china-36189636 (123)

The following command should reproduce the issue:

  python tools\perf\run_benchmark system_health.memory_desktop --story-filter=load:news:bbc --browser=release --device=desktop --browser-logging-verbosity=non-verbose

+cc shivanisha@ who added the code that calls WTFLogAlways
(https://codereview.chromium.org/2045313003).

brucedawson@: Do you have any idea what could be causing the failure?
Could it perhaps have something to do with Windows-specific line endings
(\r\n)?

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

commit 104d1e7a0e23f9e7a9fb5572026580a98d2944c0
Author: petrcermak <petrcermak@chromium.org>
Date: Fri Jul 08 16:09:41 2016

[system-health] Enable browser logging in the smoke test

BUG= 623058 , 625172 

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

[modify] https://crrev.com/104d1e7a0e23f9e7a9fb5572026580a98d2944c0/tools/perf/benchmarks/system_health_smoke_test.py

Here's the gn config of the perf builder (https://build.chromium.org/p/chromium.perf/builders/Win%20x64%20Builder/builds/10300/steps/generate_build_files/logs/stdio) for reproducing the issue:

goma_dir = "C:\\b\\build\\slave\\cache\\cipd\\goma"
is_chrome_branded = true
is_debug = false
is_official_build = true
symbol_level = 1
target_cpu = "x64"
use_goma = true

I was able to reproduce this locally and managed to grab the crash dump before it was deleted and was then able to look at the _isatty call to _invalid_parameter_noinfo:

  00000012`ad429790 00007ffc`34c45490 chrome_child!_invalid_parameter_noinfo+0x19
  00000012`ad4297d0 00007ffc`34c4b6fd chrome_child!_isatty+0x58

_isatty looks like this:

extern "C" int __cdecl _isatty(int const fh)
{
    _CHECK_FH_RETURN(fh, EBADF, 0);
    _VALIDATE_RETURN((fh >= 0 && (unsigned)fh < (unsigned)_nhandle), EBADF, 0);

    return static_cast<int>(_osfile(fh) & FDEV);
}

Looking at the stack I could see that the fh parameter to _isatty is -1, and that is triggering the call to _invalid_parameter_noinfo because that is not a valid parameter.

Looking at the FILE* object is tricky because its internal structure is not documented. It looks like __crt_stdio_stream and __crt_stdio_stream_data contain the internal representation, but further digging is probably not productive.

It looks like the FILE has already been closed?

Asides:

It would be nice if there was an easy way to retain the crash dump (I had to insert a time.sleep(1000) into one of the Python scripts) and it would be nice if the crash dump name was printed (I used procexp to figure out where it was going) and it would be nice if there was an option to save a full crash dump.

Or, best of all, if there was a way to pause the test at the beginning to give an investigator a chance to attach a debugger then this would all be much easier.

Anyway, does somebody else want to take this?

The call stack that I got was different from the one listed in the bug, but that is not actually surprising because there is nothing wrong with the call to WTFLogAlways. The problem is that stderr is corrupt or closed for some reason. Here's the call stack that I got, with arguments. Notice the 0xffffffff parameter to _isatty:

 # ChildEBP RetAddr  Args to Child              
00 0089cf94 10bf13ec 00000000 00000000 00000000 chrome_child!`anonymous namespace'::InvalidParameter+0x3 [c:\src\chromium4\src\base\win\process_startup_helper.cc @ 21]
01 0089cfb8 10bf1436 00000000 00000000 00000000 chrome_child!_invalid_parameter+0x3d [d:\th\minkernel\crts\ucrt\src\appcrt\misc\invalid_parameter.cpp @ 93]
02 0089cfd0 10c09dd2 0089cfec 10c10c1f ffffffff chrome_child!_invalid_parameter_noinfo+0xc [d:\th\minkernel\crts\ucrt\src\appcrt\misc\invalid_parameter.cpp @ 97]
03 0089cfd8 10c10c1f ffffffff 11afb780 0089d4dc chrome_child!_isatty+0x52 [d:\th\minkernel\crts\ucrt\src\appcrt\lowio\isatty.cpp @ 17]
04 0089cfec 10bf2443 11afb780 00000002 05f56078 chrome_child!__acrt_stdio_begin_temporary_buffering_nolock+0x15 [d:\th\minkernel\crts\ucrt\src\appcrt\stdio\_sftbuf.cpp @ 43]
05 (Inline) -------- -------- -------- -------- chrome_child!__acrt_stdio_temporary_buffering_guard::{ctor}+0x6 [d:\th\minkernel\crts\ucrt\inc\corecrt_internal_stdio.h @ 399]
06 0089d478 10bf1641 3c9137bb 00000002 05f56078 chrome_child!<lambda_4f2c1eaeead2a5fc776db5b62ea0fb9b>::operator()+0x23 [d:\th\minkernel\crts\ucrt\src\appcrt\stdio\output.cpp @ 36]
07 0089d4ac 10bf168f 0089d4c0 0089d4dc 0089d4c4 chrome_child!__crt_seh_guarded_call<int>::operator()<<lambda_db08b09ef7aa9d4f8620ce68402612bc>,<lambda_4f2c1eaeead2a5fc776db5b62ea0fb9b> &,<lambda_3ae262bc35d4ba6a3825c4f6bcaaf95c> >+0x27 [d:\th\minkernel\crts\ucrt\devdiv\vcruntime\inc\internal_shared.h @ 199]
08 0089d4cc 10bf4841 11afb780 0089d4dc 0089d504 chrome_child!__acrt_lock_stream_and_call<<lambda_4f2c1eaeead2a5fc776db5b62ea0fb9b> >+0x24 [d:\th\minkernel\crts\ucrt\inc\corecrt_internal_stdio.h @ 256]
09 (Inline) -------- -------- -------- -------- chrome_child!common_vfprintf+0x45 [d:\th\minkernel\crts\ucrt\src\appcrt\stdio\output.cpp @ 35]
0a 0089d508 0f175b21 00000004 00000000 11afb780 chrome_child!__stdio_common_vfprintf+0x71 [d:\th\minkernel\crts\ucrt\src\appcrt\stdio\output.cpp @ 58]
0b 0089d528 10e43080 11afb780 05f56078 00000000 chrome_child!_vfprintf_l+0x21 [c:\src\depot_tools\win_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97\win_sdk\include\10.0.10586.0\ucrt\stdio.h @ 639]
0c (Inline) -------- -------- -------- -------- chrome_child!vfprintf+0xe [c:\src\depot_tools\win_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97\win_sdk\include\10.0.10586.0\ucrt\stdio.h @ 653]
0d 0089d544 10e430d4 05f56078 0089d58c 05f56078 chrome_child!vprintf_stderr_common+0x6f [c:\src\chromium4\src\third_party\webkit\source\wtf\assertions.cpp @ 102]
0e 0089d570 10e4300d 11961788 0089d58c 0089d5a0 chrome_child!vprintf_stderr_with_trailing_newline+0x4f [c:\src\chromium4\src\third_party\webkit\source\wtf\assertions.cpp @ 123]
0f 0089d580 0f5d85fd 11961788 5a86c7e8 53a22940 chrome_child!WTFLogAlways+0xf [c:\src\chromium4\src\third_party\webkit\source\wtf\assertions.cpp @ 356]
10 0089d5a0 0f5d86f8 0089d9e8 00000003 0089d9e8 chrome_child!blink::`anonymous namespace'::emitWarningForDocWriteScripts+0xed [c:\src\chromium4\src\third_party\webkit\source\core\loader\framefetchcontext.cpp @ 88]
11 0089d5b8 0f5d8ef4 5a9e3f40 2d6486e8 0089d9e8 chrome_child!blink::`anonymous namespace'::shouldDisallowFetchForMainFrameScript+0xb8 [c:\src\chromium4\src\third_party\webkit\source\core\loader\framefetchcontext.cpp @ 122]

It would be helpful if the stack dump had included arguments - then it would have been possible to diagnose the problem without reproducing it (in theory). I'll propose a catapult change to do that.

Here's the change I made to let me grab the crash dump file, by waiting for 1,000 s before running whatever code it is that deletes it:

diff --git a/telemetry/telemetry/core/exceptions.py b/telemetry/telemetry/core/exceptions.py
index 1075625..a47f0a4 100644
--- a/telemetry/telemetry/core/exceptions.py
+++ b/telemetry/telemetry/core/exceptions.py
@@ -3,7 +3,7 @@
 # found in the LICENSE file.
 import logging
 import sys
-
+import time

 class Error(Exception):
   """Base class for Telemetry exceptions."""
@@ -81,6 +81,7 @@ class AppCrashException(Error):
   def __str__(self):
     divider = '*' * 80
     debug_messages = []
+    time.sleep(1000)
     debug_messages.append(super(AppCrashException, self).__str__())
     debug_messages.append('Found Minidump: %s' % self._is_valid_dump)
     debug_messages.append('Stack Trace:')

Also, I filed https://github.com/catapult-project/catapult/issues/2479 to request better call stacks.

It's all yours.

I think I've finally found where the issue lies: There seems to be a problem with standard output redirection in Windows when combined with logging and sandboxing.

The following command causes a renderer crash:

> out\Release_x64\chrome.exe --enable-logging http://www.bbc.co.uk/news/world-asia-china-36189636 > test.log

While the following commands work perfectly fine:

> out\Release_x64\chrome.exe --enable-logging http://www.bbc.co.uk/news/world-asia-china-36189636
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 > test.log
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636

scottmg: This issue seems related to issue 358267. Could you please help us fix the problem?

I normally use --enable-logging=stderr > log.txt 2>&1

#20: It seems that all redirections to a file cause a renderer crash when logging is enabled:

> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr > log.txt 2>&1
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr 2> log.txt
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr > log.txt
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr > log1.txt 2> log2.txt

On the other hand, the following commands work fine (no file redirection or no logging):

> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr 2>&1
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr 1>&2
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 > log.txt 2>&1
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 2> log.txt
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 > log.txt
> out\Release_x64\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 > log1.txt 2> log2.txt

I'm not sure, but my first guess would be that it's something to do with it being an Official build. Logging and Official were not really meant to be used together afaik.

This CL also might be relevant: https://codereview.chromium.org/1291553003 in particular I'd suspect the change the sandbox_win.cc which made stdio handle inheritance related to official-ness rather than --enable-logging.

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

commit 5f2967d15fe53b2bd0cec15dd22fdff3b86e1ca9
Author: scottmg <scottmg@chromium.org>
Date: Tue Aug 02 20:49:05 2016

Allow handles through for official builds too (partial revert)

This is a (very) partial revert of
https://codereview.chromium.org/1291553003 to fix the crash reported in
https://bugs.chromium.org/p/chromium/issues/detail?id=625172#c21. I
started trying to dig into making renderers log, but it's still a hairy
mess.

R=wfh@chromium.org
BUG= 625172 , 358267,  579196 
TEST=out\Release\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr > log.txt 2>&1 where chrome is is_official_build=true shouldn't crash.

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

[modify] https://crrev.com/5f2967d15fe53b2bd0cec15dd22fdff3b86e1ca9/base/process/launch_win.cc
[modify] https://crrev.com/5f2967d15fe53b2bd0cec15dd22fdff3b86e1ca9/content/common/sandbox_win.cc
[modify] https://crrev.com/5f2967d15fe53b2bd0cec15dd22fdff3b86e1ca9/content/test/content_browser_test_test.cc

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

commit 00c0c98ea999d1d8edde6d1a2c9d3e4ff1449117
Author: scottmg <scottmg@chromium.org>
Date: Tue Mar 21 19:38:37 2017

Revert of Allow handles through for official builds too (partial revert) (patchset #3 id:40001 of https://codereview.chromium.org/2198603002/ )

Reason for revert:
Potentially causing  https://crbug.com/645319 .

Graph to watch to see if it helps: https://goto.google.com/nezdg

BUG= 645319 

Original issue's description:
> Allow handles through for official builds too (partial revert)
>
> This is a (very) partial revert of
> https://codereview.chromium.org/1291553003 to fix the crash reported in
> https://bugs.chromium.org/p/chromium/issues/detail?id=625172#c21. I
> started trying to dig into making renderers log, but it's still a hairy
> mess.
>
> R=wfh@chromium.org
> BUG= 625172 , 358267,  579196 
> TEST=out\Release\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr > log.txt 2>&1 where chrome is is_official_build=true shouldn't crash.
>
> Committed: https://crrev.com/5f2967d15fe53b2bd0cec15dd22fdff3b86e1ca9
> Cr-Commit-Position: refs/heads/master@{#409318}

TBR=wfh@chromium.org,sky@chromium.org,thestig@chromium.org
# Not skipping CQ checks because original CL landed more than 1 days ago.
BUG= 625172 , 358267,  579196 

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

[modify] https://crrev.com/00c0c98ea999d1d8edde6d1a2c9d3e4ff1449117/base/process/launch_win.cc
[modify] https://crrev.com/00c0c98ea999d1d8edde6d1a2c9d3e4ff1449117/content/common/sandbox_win.cc
[modify] https://crrev.com/00c0c98ea999d1d8edde6d1a2c9d3e4ff1449117/content/test/content_browser_test_test.cc

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

commit 7b8448f77e91f2ef81e4c36929454c321895ecd7
Author: Scott Graham <scottmg@chromium.org>
Date: Mon Apr 10 20:25:14 2017

Revert of Allow handles through for official builds too (partial revert) (patchset #3 id:40001 of https://codereview.chromium.org/2198603002/ )

Reason for revert:
Potentially causing  https://crbug.com/645319 .

Graph to watch to see if it helps: https://goto.google.com/nezdg

BUG= 645319 

Original issue's description:
> Allow handles through for official builds too (partial revert)
>
> This is a (very) partial revert of
> https://codereview.chromium.org/1291553003 to fix the crash reported in
> https://bugs.chromium.org/p/chromium/issues/detail?id=625172#c21. I
> started trying to dig into making renderers log, but it's still a hairy
> mess.
>
> R=wfh@chromium.org
> BUG= 625172 , 358267,  579196 
> TEST=out\Release\chrome.exe http://www.bbc.co.uk/news/world-asia-china-36189636 --enable-logging=stderr > log.txt 2>&1 where chrome is is_official_build=true shouldn't crash.
>
> Committed: https://crrev.com/5f2967d15fe53b2bd0cec15dd22fdff3b86e1ca9
> Cr-Commit-Position: refs/heads/master@{#409318}

TBR=wfh@chromium.org,sky@chromium.org,thestig@chromium.org
BUG= 625172 , 358267,  579196 

Review-Url: https://codereview.chromium.org/2767663002
Cr-Commit-Position: refs/heads/master@{#458513}
(cherry picked from commit 00c0c98ea999d1d8edde6d1a2c9d3e4ff1449117)

Review-Url: https://codereview.chromium.org/2810903002 .
Cr-Commit-Position: refs/branch-heads/3029@{#653}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/7b8448f77e91f2ef81e4c36929454c321895ecd7/base/process/launch_win.cc
[modify] https://crrev.com/7b8448f77e91f2ef81e4c36929454c321895ecd7/content/common/sandbox_win.cc
[modify] https://crrev.com/7b8448f77e91f2ef81e4c36929454c321895ecd7/content/test/content_browser_test_test.cc