Statically link libprotobuf_lite on Linux component builds

Statically link libprotobuf_lite on Linux component builds

Chrome has a direct dependency on a custom libprotobuf_lite in
third_party, but Xenial and Yakkety add a dependency on the system
libprotobuf-lite via Mir (which gets loaded from Gtk).

Our third_party protobuf is not compatible with the upstream protobuf.
Combine this with the fact that Xenial uses version 2 while Yakkety
uses version 3, and it's basically impossible to make our third_party
protobuf cooperate with the system one.  The solution is to always
statically link protobuf on Linux.

This alone, however, is not enough to fix the issue on component
builds.  If components A and B both have private copies of
libprotobuf_lite, they have their own sets of globals.  A problematic
global is "std::string* google::protobuf::internal::empty_string_".
Protobuf does pointer comparison against this string to determine if
strings are empty.  This is problematic when data is passed from
component A to B, each of which have an empty_string_ at a different
address.

This CL also extracts these types of globals into their own shared
library so they can be shared among Chromium components. It also
adds a 'cr_' prefix to them so they cannot conflict with the system
protobuf.

This change only affects desktop Linux component builds.  Release
binaries and debug binaries on other platforms should be unaffected.

Finally, this CL is a hack, and it should be reverted when a
longer-term solution is implemented.

BUG=79722, 700120
R=pkasting@chromium.org
TBR=bengr@chromium.org
CC=dpranke@chromium.org,rsimha@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng;master.tryserver.chromium.win:win_chromium_dbg_ng

patch from issue 2746493002 at patchset 260001 (http://crrev.com/2746493002#ps260001)

Review-Url: https://codereview.chromium.org/2756543002
Cr-Commit-Position: refs/heads/master@{#458016}
Committed: https://chromium.googlesource.com/chromium/src/+/77bec4dfd9e172a99543b9bfe9daf2580721bfdd

[Tom (Use chromium acct), 2017-03-15 19:13:32]

pkasting ptal

I removed win_chromium_dbg_ng from CQ_INCLUDE_TRYBOTS because
telementry_unittests is currently broken on win dbg (crbug.com/701691)

[Peter Kasting, 2017-03-15 21:53:52]

I think we need to fix the other globals mentioned on the email thread too
(message default instances).

I'm worried about other cases as well.  This might be an OK band-aid, but even
in the absence of any upstream fix, please do check into the other ideas on that
thread (symbol versioning, "whatever libpng does").

LGTM

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/BUILD.gn
File third_party/protobuf/BUILD.gn (right):

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/BUILD....
third_party/protobuf/BUILD.gn:151: if (is_component_build && is_linux &&
!is_chromeos) {
Nit: This deserves a comment about what it's doing and why, and maybe how we'd
know if it were ever safe to remove this.

[bengr, 2017-03-16 18:38:14]

lgtm otherwise.

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/src/go...
File third_party/protobuf/src/google/protobuf/globals.cc (right):

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/src/go...
third_party/protobuf/src/google/protobuf/globals.cc:1: #include
<google/protobuf/generated_message_util.h>
You might want to add a license comment, e.g.,
https://codesearch.chromium.org/chromium/src/third_party/protobuf/src/google/...

[Tom (Use chromium acct), 2017-03-18 00:11:17]

Description was changed from

==========
Statically link libprotobuf_lite on Linux component builds

Chrome has a direct dependency on a custom libprotobuf_lite in
third_party, but Xenial and Yakkety add a dependency on the system
libprotobuf-lite via Mir (which gets loaded from Gtk).

Our third_party protobuf is not compatible with the upstream protobuf.
Combine this with the fact that Xenial uses version 2 while Yakkety
uses version 3, and it's basically impossible to make our third_party
protobuf cooperate with the system one.  The solution is to always
statically link protobuf on Linux.

This alone, however, is not enough to fix the issue on component
builds.  If components A and B both have private copies of
libprotobuf_lite, they have their own sets of globals.  A problematic
global is "std::string* google::protobuf::internal::empty_string_".
Protobuf does pointer comparison against this string to determine if
strings are empty.  This is problematic when data is passed from
component A to B, each of which have an empty_string_ at a different
address.

This CL also extracts empty_string_ into its own shared library so it
can be shared among Chromium components, and renames it to
cr_empty_string_ so it cannot conflict with the system protobuf.

This change only affects desktop Linux component builds.  Release
binaries and debug binaries on other platforms should be identical.

Finally, this CL is a hack, and it should be reverted when a
longer-term solution is implemented.

BUG=79722,700120
R=pkasting@chromium.org
TBR=bengr@chromium.org
CC=dpranke@chromium.org,rsimha@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng

patch from issue 2746493002 at patchset 260001
(http://crrev.com/2746493002#ps260001)
==========

to

==========
Statically link libprotobuf_lite on Linux component builds

Chrome has a direct dependency on a custom libprotobuf_lite in
third_party, but Xenial and Yakkety add a dependency on the system
libprotobuf-lite via Mir (which gets loaded from Gtk).

Our third_party protobuf is not compatible with the upstream protobuf.
Combine this with the fact that Xenial uses version 2 while Yakkety
uses version 3, and it's basically impossible to make our third_party
protobuf cooperate with the system one.  The solution is to always
statically link protobuf on Linux.

This alone, however, is not enough to fix the issue on component
builds.  If components A and B both have private copies of
libprotobuf_lite, they have their own sets of globals.  A problematic
global is "std::string* google::protobuf::internal::empty_string_".
Protobuf does pointer comparison against this string to determine if
strings are empty.  This is problematic when data is passed from
component A to B, each of which have an empty_string_ at a different
address.

This CL also extracts empty_string_ into its own shared library so it
can be shared among Chromium components, and renames it to
cr_empty_string_ so it cannot conflict with the system protobuf.

This change only affects desktop Linux component builds.  Release
binaries and debug binaries on other platforms should be identical.

Finally, this CL is a hack, and it should be reverted when a
longer-term solution is implemented.

BUG=79722,700120
R=pkasting@chromium.org
TBR=bengr@chromium.org
CC=dpranke@chromium.org,rsimha@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng;master.tryserver.chromium.win:win_chromium_dbg_ng

patch from issue 2746493002 at patchset 260001
(http://crrev.com/2746493002#ps260001)
==========

[Tom (Use chromium acct), 2017-03-18 00:11:22]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 00:11:58]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2017-03-18 00:12:53]

Description was changed from

==========
Statically link libprotobuf_lite on Linux component builds

Chrome has a direct dependency on a custom libprotobuf_lite in
third_party, but Xenial and Yakkety add a dependency on the system
libprotobuf-lite via Mir (which gets loaded from Gtk).

Our third_party protobuf is not compatible with the upstream protobuf.
Combine this with the fact that Xenial uses version 2 while Yakkety
uses version 3, and it's basically impossible to make our third_party
protobuf cooperate with the system one.  The solution is to always
statically link protobuf on Linux.

This alone, however, is not enough to fix the issue on component
builds.  If components A and B both have private copies of
libprotobuf_lite, they have their own sets of globals.  A problematic
global is "std::string* google::protobuf::internal::empty_string_".
Protobuf does pointer comparison against this string to determine if
strings are empty.  This is problematic when data is passed from
component A to B, each of which have an empty_string_ at a different
address.

This CL also extracts empty_string_ into its own shared library so it
can be shared among Chromium components, and renames it to
cr_empty_string_ so it cannot conflict with the system protobuf.

This change only affects desktop Linux component builds.  Release
binaries and debug binaries on other platforms should be identical.

Finally, this CL is a hack, and it should be reverted when a
longer-term solution is implemented.

BUG=79722,700120
R=pkasting@chromium.org
TBR=bengr@chromium.org
CC=dpranke@chromium.org,rsimha@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng;master.tryserver.chromium.win:win_chromium_dbg_ng

patch from issue 2746493002 at patchset 260001
(http://crrev.com/2746493002#ps260001)
==========

to

==========
Statically link libprotobuf_lite on Linux component builds

Chrome has a direct dependency on a custom libprotobuf_lite in
third_party, but Xenial and Yakkety add a dependency on the system
libprotobuf-lite via Mir (which gets loaded from Gtk).

Our third_party protobuf is not compatible with the upstream protobuf.
Combine this with the fact that Xenial uses version 2 while Yakkety
uses version 3, and it's basically impossible to make our third_party
protobuf cooperate with the system one.  The solution is to always
statically link protobuf on Linux.

This alone, however, is not enough to fix the issue on component
builds.  If components A and B both have private copies of
libprotobuf_lite, they have their own sets of globals.  A problematic
global is "std::string* google::protobuf::internal::empty_string_".
Protobuf does pointer comparison against this string to determine if
strings are empty.  This is problematic when data is passed from
component A to B, each of which have an empty_string_ at a different
address.

This CL also extracts these types of globals into their own shared
library so they can be shared among Chromium components. It also
adds a 'cr_' prefix to them so they cannot conflict with the system
protobuf.

This change only affects desktop Linux component builds.  Release
binaries and debug binaries on other platforms should be unaffected.

Finally, this CL is a hack, and it should be reverted when a
longer-term solution is implemented.

BUG=79722,700120
R=pkasting@chromium.org
TBR=bengr@chromium.org
CC=dpranke@chromium.org,rsimha@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng;master.tryserver.chromium.win:win_chromium_dbg_ng

patch from issue 2746493002 at patchset 260001
(http://crrev.com/2746493002#ps260001)
==========

[commit-bot: I haz the power, 2017-03-18 00:20:41]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-18 00:20:42]

Dry run: Try jobs failed on following builders:
  android_cronet on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_cron...)
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)

[Tom (Use chromium acct), 2017-03-18 00:44:21]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 00:45:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-18 00:55:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-18 00:55:23]

Dry run: Try jobs failed on following builders:
  cast_shell_android on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/cast_shell_a...)
  ios-device on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device/builds...)
  ios-simulator on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator/bui...)

[Tom (Use chromium acct), 2017-03-18 01:14:42]

Patchset #2 (id:20001) has been deleted

[Tom (Use chromium acct), 2017-03-18 01:14:50]

Patchset #2 (id:40001) has been deleted

[Tom (Use chromium acct), 2017-03-18 01:16:38]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 01:17:18]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-18 01:26:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-18 01:26:12]

Dry run: Try jobs failed on following builders:
  ios-device-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-device-xcode-...)
  ios-simulator-xcode-clang on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/ios-simulator-xco...)
  mac_chromium_compile_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_comp...)
  mac_chromium_dbg_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_dbg_...)

[Tom (Use chromium acct), 2017-03-18 01:30:39]

Patchset #2 (id:60001) has been deleted

[Tom (Use chromium acct), 2017-03-18 01:30:44]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 01:31:22]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2017-03-18 01:47:41]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 01:48:13]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-18 02:20:16]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-18 02:20:17]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[Tom (Use chromium acct), 2017-03-18 02:47:33]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 02:47:53]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-18 03:33:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-18 03:33:05]

Dry run: Try jobs failed on following builders:
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[Tom (Use chromium acct), 2017-03-18 05:06:00]

Patchset #2 (id:80001) has been deleted

[Tom (Use chromium acct), 2017-03-18 05:06:12]

Patchset #2 (id:100001) has been deleted

[Tom (Use chromium acct), 2017-03-18 05:20:20]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 05:20:33]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2017-03-18 05:43:49]

The CQ bit was checked by thomasanderson@google.com to run a CQ dry run

[commit-bot: I haz the power, 2017-03-18 05:44:02]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Tom (Use chromium acct), 2017-03-18 05:44:07]

Patchset #2 (id:120001) has been deleted

[Tom (Use chromium acct), 2017-03-18 06:32:09]

Patchset #2 (id:140001) has been deleted

[commit-bot: I haz the power, 2017-03-18 07:36:22]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-18 07:36:23]

Dry run: This issue passed the CQ dry run.

[Tom (Use chromium acct), 2017-03-19 07:19:11]

There's quite a few changes since PS1 since I moved all data symbols to
globals.cc.  I'm confident that this should fix all data-sharing issues, but I
guess now I'm on the hook for maintaining it :)

I'll land this tomorrow unless there are any objections.  (Note that I reverted
the Gtk3 change last week, so the issue is not blocking any devs atm)

On 2017/03/15 21:53:52, Peter Kasting wrote:
> I think we need to fix the other globals mentioned on the email thread too
> (message default instances).
> 

Done.  

> I'm worried about other cases as well.  This might be an OK band-aid, but even
> in the absence of any upstream fix, please do check into the other ideas on
that
> thread (symbol versioning, "whatever libpng does").

I spent much of last week trying other solutions, and I was unable to get any of
them working.

Symbol versioning seemed the most promising, because it was meant to solve this
exact issue, and the fix is a one-liner.  However, for technical reasons, the
system protobuf must be versioned as well, but it is not.  Most libraries add a
harmless @@Base version, which can easily be added upstream.  Unfortunately,
Ubuntu Xenial and Yakkety will still be using the old protobuf (those distros
need to be supported for ~5 more years) unless we can convince Canonical to
backport the fix.

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/BUILD.gn
File third_party/protobuf/BUILD.gn (right):

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/BUILD....
third_party/protobuf/BUILD.gn:151: if (is_component_build && is_linux &&
!is_chromeos) {
On 2017/03/15 21:53:52, Peter Kasting wrote:
> Nit: This deserves a comment about what it's doing and why, and maybe how we'd
> know if it were ever safe to remove this.

Done.

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/src/go...
File third_party/protobuf/src/google/protobuf/globals.cc (right):

https://codereview.chromium.org/2756543002/diff/1/third_party/protobuf/src/go...
third_party/protobuf/src/google/protobuf/globals.cc:1: #include
<google/protobuf/generated_message_util.h>
On 2017/03/16 18:38:13, bengr wrote:
> You might want to add a license comment, e.g.,
>
https://codesearch.chromium.org/chromium/src/third_party/protobuf/src/google/...
> 

Done.

[Peter Kasting, 2017-03-19 22:37:59]

On 2017/03/19 07:19:11, Tom Anderson wrote:
> Symbol versioning seemed the most promising, because it was meant to solve
this
> exact issue, and the fix is a one-liner.  However, for technical reasons, the
> system protobuf must be versioned as well, but it is not.  Most libraries add
a
> harmless @@Base version, which can easily be added upstream.  Unfortunately,
> Ubuntu Xenial and Yakkety will still be using the old protobuf (those distros
> need to be supported for ~5 more years) unless we can convince Canonical to
> backport the fix.

I think we should ask them to do so.

It seems like it's extremely low-cost and low-risk for them to add this, and it
was a high maintenance benefit on our side.

[Tom (Use chromium acct), 2017-03-20 01:39:40]

The CQ bit was checked by thomasanderson@google.com

[Tom (Use chromium acct), 2017-03-20 01:39:41]

The patchset sent to the CQ was uploaded after l-g-t-m from bengr@chromium.org,
pkasting@chromium.org
Link to the patchset: https://codereview.chromium.org/2756543002/#ps160001
(title: "Extract all global data to globals.cc")

[commit-bot: I haz the power, 2017-03-20 01:39:51]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-20 07:09:30]

CQ is committing da patch.

Bot data: {"patchset_id": 160001, "attempt_start_ts": 1489973980723550,
"parent_rev": "e73b84f523d42ccc7406721a33c263235639fd1e", "commit_rev":
"77bec4dfd9e172a99543b9bfe9daf2580721bfdd"}

[commit-bot: I haz the power, 2017-03-20 07:11:19]

Description was changed from

==========
Statically link libprotobuf_lite on Linux component builds

Chrome has a direct dependency on a custom libprotobuf_lite in
third_party, but Xenial and Yakkety add a dependency on the system
libprotobuf-lite via Mir (which gets loaded from Gtk).

Our third_party protobuf is not compatible with the upstream protobuf.
Combine this with the fact that Xenial uses version 2 while Yakkety
uses version 3, and it's basically impossible to make our third_party
protobuf cooperate with the system one.  The solution is to always
statically link protobuf on Linux.

This alone, however, is not enough to fix the issue on component
builds.  If components A and B both have private copies of
libprotobuf_lite, they have their own sets of globals.  A problematic
global is "std::string* google::protobuf::internal::empty_string_".
Protobuf does pointer comparison against this string to determine if
strings are empty.  This is problematic when data is passed from
component A to B, each of which have an empty_string_ at a different
address.

This CL also extracts these types of globals into their own shared
library so they can be shared among Chromium components. It also
adds a 'cr_' prefix to them so they cannot conflict with the system
protobuf.

This change only affects desktop Linux component builds.  Release
binaries and debug binaries on other platforms should be unaffected.

Finally, this CL is a hack, and it should be reverted when a
longer-term solution is implemented.

BUG=79722,700120
R=pkasting@chromium.org
TBR=bengr@chromium.org
CC=dpranke@chromium.org,rsimha@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng;master.tryserver.chromium.win:win_chromium_dbg_ng

patch from issue 2746493002 at patchset 260001
(http://crrev.com/2746493002#ps260001)
==========

to

==========
Statically link libprotobuf_lite on Linux component builds

Chrome has a direct dependency on a custom libprotobuf_lite in
third_party, but Xenial and Yakkety add a dependency on the system
libprotobuf-lite via Mir (which gets loaded from Gtk).

Our third_party protobuf is not compatible with the upstream protobuf.
Combine this with the fact that Xenial uses version 2 while Yakkety
uses version 3, and it's basically impossible to make our third_party
protobuf cooperate with the system one.  The solution is to always
statically link protobuf on Linux.

This alone, however, is not enough to fix the issue on component
builds.  If components A and B both have private copies of
libprotobuf_lite, they have their own sets of globals.  A problematic
global is "std::string* google::protobuf::internal::empty_string_".
Protobuf does pointer comparison against this string to determine if
strings are empty.  This is problematic when data is passed from
component A to B, each of which have an empty_string_ at a different
address.

This CL also extracts these types of globals into their own shared
library so they can be shared among Chromium components. It also
adds a 'cr_' prefix to them so they cannot conflict with the system
protobuf.

This change only affects desktop Linux component builds.  Release
binaries and debug binaries on other platforms should be unaffected.

Finally, this CL is a hack, and it should be reverted when a
longer-term solution is implemented.

BUG=79722,700120
R=pkasting@chromium.org
TBR=bengr@chromium.org
CC=dpranke@chromium.org,rsimha@chromium.org
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_dbg_ng;master.tryserver.chromium.mac:mac_chromium_dbg_ng;master.tryserver.chromium.win:win_chromium_dbg_ng

patch from issue 2746493002 at patchset 260001
(http://crrev.com/2746493002#ps260001)

Review-Url: https://codereview.chromium.org/2756543002
Cr-Commit-Position: refs/heads/master@{#458016}
Committed:
https://chromium.googlesource.com/chromium/src/+/77bec4dfd9e172a99543b9bfe9da...
==========

[commit-bot: I haz the power, 2017-03-20 07:11:20]

Committed patchset #2 (id:160001) as
https://chromium.googlesource.com/chromium/src/+/77bec4dfd9e172a99543b9bfe9da...