Disable tcmalloc when building for valgrind

Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools. Today we already set
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and run with valgrind out/Release/chrome --no-sandbox

Committed: https://crrev.com/65aeea273767bd69a8824e36972995b278161089
Cr-Commit-Position: refs/heads/master@{#373835}

[Primiano Tucci (use gerrit), 2016-02-03 17:33:42]

Description was changed from

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools (even before this CL,
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
==========

to

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools (even before this CL,
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and
run with valgrind out/Release/chrome --no-sandbox
==========

[Primiano Tucci (use gerrit), 2016-02-03 17:33:42]

primiano@chromium.org changed reviewers:
+ bratell@opera.com, thakis@chromium.org

[Primiano Tucci (use gerrit), 2016-02-03 17:34:13]

Description was changed from

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools (even before this CL,
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and
run with valgrind out/Release/chrome --no-sandbox
==========

to

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools. Today we already set
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and
run with valgrind out/Release/chrome --no-sandbox
==========

[Primiano Tucci (use gerrit), 2016-02-03 17:37:59]

Daniel, this seems to solve your problem.
Nico: PTAL 1 line change.

I didn't find an equivalent to this in GN files. I think nobody bothered doing
an equivalent of that there.
Also, looking quickly at the build flags, I suspect that you can achieve the
same in GN by just setting:

enable_profiling=1
use_allocator='none'

[Daniel Bratell, 2016-02-04 13:46:49]

On 2016/02/03 17:37:59, Primiano Tucci wrote:
> Daniel, this seems to solve your problem.

I've tested and it does! Official valgrind (3.11) crashed quite early because it
didn't understand the 480FC7F3 instruction (rdrand) used in boringssl but
valgrind-variant succeeded. I suspect valgrind-variant emulates an older x86_64
cpu. So non-owner lgtm.

[Nico, 2016-02-04 14:54:25]

lgtm

A bit weird to not use the allocator we ship with on the memory test bots, but I
suppose that's the current state of the world already :-/

[Primiano Tucci (use gerrit), 2016-02-04 15:50:31]

On 2016/02/04 14:54:25, Nico wrote:
> lgtm
> 
> A bit weird to not use the allocator we ship with on the memory test bots, but
I
> suppose that's the current state of the world already :-/

Dunno. I can see that tcmalloc has code that seems to intend to be
valgrind-friendly (see [1] as an example).
I just guess that it just became not valgrind-bleeding-edge-friendly anymore?

[1]
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/tcmall...

[Primiano Tucci (use gerrit), 2016-02-04 15:50:35]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2016-02-04 15:51:18]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1668643002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1668643002/1

[Daniel Bratell, 2016-02-04 16:42:17]

On 2016/02/04 15:50:31, Primiano Tucci wrote:

> I just guess that it just became not valgrind-bleeding-edge-friendly anymore?

Seems to be fixed in valgrind a while ago, but not yet released:
https://bugs.kde.org/show_bug.cgi?id=353370

So I could compile from svn and check if it works better there. There is another
issue related to this failure btw. The instruction not supported was rdrand
which boringssl uses for entropy. There has been some controversy around that
instruction.

[Daniel Bratell, 2016-02-04 16:52:15]

On 2016/02/04 16:42:17, Daniel Bratell wrote:
> On 2016/02/04 15:50:31, Primiano Tucci wrote:
> 
> > I just guess that it just became not valgrind-bleeding-edge-friendly
anymore?
> 
> Seems to be fixed in valgrind a while ago, but not yet released:
> https://bugs.kde.org/show_bug.cgi?id=353370
> 
> So I could compile from svn and check if it works better there. There is
another
> issue related to this failure btw. The instruction not supported was rdrand
> which boringssl uses for entropy. There has been some controversy around that
> instruction.

Trunk valgrind (hopefully released as 3.12 eventually) seems to work fine. And
someone should look at memory usage in the CRL system...

[commit-bot: I haz the power, 2016-02-04 16:57:59]

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

[commit-bot: I haz the power, 2016-02-04 16:58:00]

Try jobs failed on following builders:
  mac_chromium_rel_ng on tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Primiano Tucci (use gerrit), 2016-02-05 15:51:24]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2016-02-05 15:51:56]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1668643002/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1668643002/1

[commit-bot: I haz the power, 2016-02-05 17:15:02]

Description was changed from

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools. Today we already set
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and
run with valgrind out/Release/chrome --no-sandbox
==========

to

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools. Today we already set
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and
run with valgrind out/Release/chrome --no-sandbox
==========

[commit-bot: I haz the power, 2016-02-05 17:15:03]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2016-02-05 17:16:10]

Description was changed from

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools. Today we already set
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and
run with valgrind out/Release/chrome --no-sandbox
==========

to

==========
Disable tcmalloc when building for valgrind

tcmalloc doesn't seem to play well with Valgrind. See crbug.com/582398
and the discussion in crrev.com/1642383002 .
On top of that, routing to the system allocator seems consistent with
what we already do in the case of other tools. Today we already set
use_allocator='none' if (asan==1 or msan==1 or lsan==1 or tsan==1).

BUG=582398
TEST=build with GYP_DEFINES="build_for_tool=memcheck clang=1 profiling=1" and
run with valgrind out/Release/chrome --no-sandbox

Committed: https://crrev.com/65aeea273767bd69a8824e36972995b278161089
Cr-Commit-Position: refs/heads/master@{#373835}
==========

[commit-bot: I haz the power, 2016-02-05 17:16:11]

Patchset 1 (id:??) landed as
https://crrev.com/65aeea273767bd69a8824e36972995b278161089
Cr-Commit-Position: refs/heads/master@{#373835}