android: Enable death on malloc/operator new failure.

android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

Note also that this CL is just about inducing a hard crash on malloc failure.
This does not change the situation about disallowing large allocations
(>2GB) that might cause int signed/unsigned bugs
(see crbug.com/169327). As things stand today, Android never had that
check and still doesn't yet after this CL.

BUG=633966, 317791
TEST=base_unittests --gtest_filter=OutOfMemory*

Committed: https://crrev.com/227dbd3dc564004471f146ef655fad35c52704c3
Cr-Commit-Position: refs/heads/master@{#409531}

[Primiano Tucci (use gerrit), 2016-08-03 11:27:07]

The CQ bit was checked by primiano@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-03 11:27:34]

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

[Primiano Tucci (use gerrit), 2016-08-03 11:27:56]

Description was changed from

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx (see crbug.com/317791).

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new secure again.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim didn't realize about
  the missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixeds all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633313,317791
==========

to

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx (see crbug.com/317791).

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim didn't realize about
  the missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixeds all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633313,317791
==========

[Primiano Tucci (use gerrit), 2016-08-03 11:28:11]

Description was changed from

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx (see crbug.com/317791).

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim didn't realize about
  the missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixeds all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633313,317791
==========

to

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx (see crbug.com/317791).

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim didn't realize about
  the missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633313,317791
==========

[Primiano Tucci (use gerrit), 2016-08-03 11:30:13]

primiano@chromium.org changed reviewers:
+ torne@chromium.org, wfh@chromium.org

[Primiano Tucci (use gerrit), 2016-08-03 11:30:14]

https://codereview.chromium.org/2201363002/diff/1/base/process/memory_unittes...
File base/process/memory_unittest.cc (left):

https://codereview.chromium.org/2201363002/diff/1/base/process/memory_unittes...
base/process/memory_unittest.cc:418: #if
!defined(MEMORY_TOOL_REPLACES_ALLOCATOR)
This #if is redundant as the entire block is already ifdefed out above if
!MEMORY_TOOL_REPLACES_ALLOCATOR

[Torne, 2016-08-03 11:34:00]

LGTM, thanks!

[Primiano Tucci (use gerrit), 2016-08-03 12:24:05]

primiano@chromium.org changed reviewers:
+ thakis@chromium.org

[Primiano Tucci (use gerrit), 2016-08-03 12:24:06]

actually +thakis as this is in //base/process

[Primiano Tucci (use gerrit), 2016-08-03 12:25:54]

Description was changed from

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx (see crbug.com/317791).

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim didn't realize about
  the missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633313,317791
==========

to

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633313,317791
==========

[commit-bot: I haz the power, 2016-08-03 12:29:52]

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

[commit-bot: I haz the power, 2016-08-03 12:29:53]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[Primiano Tucci (use gerrit), 2016-08-03 12:34:18]

Description was changed from

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633313,317791
==========

to

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633966,317791
TEST=base_unittests --gtest_filter=OutOfMemory*
==========

[Primiano Tucci (use gerrit), 2016-08-03 12:35:37]

On 2016/08/03 12:24:06, Primiano Tucci wrote:
> actually +thakis as this is in //base/process

Hold on, the #ifdef condition in the test is still wrong for the
OutOfMemoryDeathTest, as it is enabled only on win. Fixing this soon. Apologies
for the back and forth.

[Primiano Tucci (use gerrit), 2016-08-03 12:52:18]

On 2016/08/03 12:35:37, Primiano Tucci wrote:
> On 2016/08/03 12:24:06, Primiano Tucci wrote:
> > actually +thakis as this is in //base/process
> 
> Hold on, the #ifdef condition in the test is still wrong for the
> OutOfMemoryDeathTest, as it is enabled only on win. Fixing this soon.
Apologies
> for the back and forth.

Take it back, the CL itself is clear to review.

I see what's going on. I was mislead by that "WIN" in
ENABLE_WIN_ALLOCATOR_SHIM_TESTS, but checking more thoroughly
ENABLE_WIN_ALLOCATOR_SHIM_TESTS = ($use_experimental_allocator_shim ||
$win_use_allocator_shim win_use_allocator_shim), so besides naming it's all as
it should be (the flag should be called just  ENABLE_ALLOCATOR_SHIM_TESTS,
without WIN). 
So I think the code of this CL is okay.

The real problem is that death tests don't seem to be supported on Android,
that's why I couldn't find them in the base_unittests output of the
android_rel_ng bot.
The OutOfMemoryDeathTest here is not running because of the *DeathTest*
exclusion in build/android/pylib/gtest/filter/base_unittests_disabled
Will check with jbudorick whether this is intended, but in the meantime this CL
is clear to review

[Primiano Tucci (use gerrit), 2016-08-03 13:07:51]

The CQ bit was checked by primiano@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-03 13:08:04]

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

[Primiano Tucci (use gerrit), 2016-08-03 13:09:13]

Had a chat with jbudorick. death tests seem to work on Android.
I think these specific test got blacklisted because they were failing (not
because of death tests itself).
In turn they were failing because of the thing I am fixing in this CL: they were
not invoking OnNoMemory and failing the regex matching.

[Primiano Tucci (use gerrit), 2016-08-03 13:28:30]

The CQ bit was checked by primiano@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-03 13:28:45]

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

[Nico, 2016-08-03 14:13:20]

lgtm

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
File base/process/memory_unittest.cc (right):

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
base/process/memory_unittest.cc:190: #if !defined(OS_MACOSX) &&
!defined(OS_ANDROID)
Why ifdef out these tests? Maybe update the comment two lines above.

[Primiano Tucci (use gerrit), 2016-08-03 15:02:42]

The CQ bit was checked by primiano@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-03 15:03:03]

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

[Primiano Tucci (use gerrit), 2016-08-03 15:04:48]

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
File base/process/memory_unittest.cc (right):

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
base/process/memory_unittest.cc:190: #if !defined(OS_MACOSX) &&
!defined(OS_ANDROID)
On 2016/08/03 14:13:20, Nico wrote:
> Why ifdef out these tests? Maybe update the comment two lines above.

So the thing is that, as things stands today, Android doesn't have the 2gb check
just because nobody bothered there. This test was passing just because the
virtual address space is so fragmented by the zygote that is practically
impossible to mmap/malloc(2GB). 
Having said that, we should probably fix the glitch and move that code from
win-only to the shim, but that is something that I don't want to do here because
would be new for Android and I have no idea if will just work(TM)

[Primiano Tucci (use gerrit), 2016-08-03 15:06:28]

The CQ bit was unchecked by primiano@chromium.org

[Primiano Tucci (use gerrit), 2016-08-03 15:06:37]

The CQ bit was checked by primiano@chromium.org

[Primiano Tucci (use gerrit), 2016-08-03 15:06:37]

The patchset sent to the CQ was uploaded after l-g-t-m from torne@chromium.org,
thakis@chromium.org
Link to the patchset: https://codereview.chromium.org/2201363002/#ps60001
(title: "fix comment")

[commit-bot: I haz the power, 2016-08-03 15:06:49]

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

[Nico, 2016-08-03 15:06:52]

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
File base/process/memory_unittest.cc (right):

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
base/process/memory_unittest.cc:190: #if !defined(OS_MACOSX) &&
!defined(OS_ANDROID)
On 2016/08/03 15:04:48, Primiano Tucci wrote:
> On 2016/08/03 14:13:20, Nico wrote:
> > Why ifdef out these tests? Maybe update the comment two lines above.
> 
> So the thing is that, as things stands today, Android doesn't have the 2gb
check
> just because nobody bothered there. This test was passing just because the
> virtual address space is so fragmented by the zygote that is practically
> impossible to mmap/malloc(2GB). 
> Having said that, we should probably fix the glitch and move that code from
> win-only to the shim, but that is something that I don't want to do here
because
> would be new for Android and I have no idea if will just work(TM)

Doesn't this test run on linux as well? Or am I missing an ifdef somewhere? If
it runs on linux, how can it work if the check for this is in a win-only file?

[Torne, 2016-08-03 15:08:59]

On 2016/08/03 15:04:48, Primiano Tucci wrote:
>
https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
> File base/process/memory_unittest.cc (right):
> 
>
https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
> base/process/memory_unittest.cc:190: #if !defined(OS_MACOSX) &&
> !defined(OS_ANDROID)
> On 2016/08/03 14:13:20, Nico wrote:
> > Why ifdef out these tests? Maybe update the comment two lines above.
> 
> So the thing is that, as things stands today, Android doesn't have the 2gb
check
> just because nobody bothered there. This test was passing just because the
> virtual address space is so fragmented by the zygote that is practically
> impossible to mmap/malloc(2GB). 

Well, only because we only build/test 32-bit, right? If we'd tested on 64-bit it
would fail I assume. Not disagreeing with disabling the test, though.

> Having said that, we should probably fix the glitch and move that code from
> win-only to the shim, but that is something that I don't want to do here
because
> would be new for Android and I have no idea if will just work(TM)

[Primiano Tucci (use gerrit), 2016-08-03 15:12:48]

The CQ bit was unchecked by primiano@chromium.org

[Primiano Tucci (use gerrit), 2016-08-03 15:21:45]

On 2016/08/03 15:08:59, Torne wrote:
> Well, only because we only build/test 32-bit, right? If we'd tested on 64-bit
it
> would fail I assume. Not disagreeing with disabling the test, though.

Right. I am not saying that "we are good" an android.
I am just saying that on 32 bit we are safe by accident. I am disabling the test
because that passes only because of address space fragmentation and can become
flaky. Also would fail on 64 bit. 

I am also not saying that we are good and shouldn't do anything more for the 2gb
allocations on Android. But this is the current state (even before M51), we
never had this check. Adding that would be simple, but I don't want to enable
just here, as that might create some other problem.
I'll update that bug asking about feedback on adding the 2GB limit on Android,
and if there are no objection will add that in a separate patch.

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
File base/process/memory_unittest.cc (right):

https://codereview.chromium.org/2201363002/diff/40001/base/process/memory_uni...
base/process/memory_unittest.cc:190: #if !defined(OS_MACOSX) &&
!defined(OS_ANDROID)
On 2016/08/03 15:06:52, Nico wrote:
> Doesn't this test run on linux as well?
Yes, it does. See logdog output for this CL in https://goo.gl/3Vc5DP

> Or am I missing an ifdef somewhere? If
> it runs on linux, how can it work if the check for this is in a win-only file?
This is not a win-only file (that WIN in the name of
ENABLE_WIN_ALLOCATOR_SHIM_TESTS is misleading)

On Linux desktop this is working because tcmalloc has baked in the 2GB limit
check.
See  IsAllocSizePermitted in tcmalloc.cc
(https://cs.chromium.org/chromium/src/third_party/tcmalloc/chromium/src/tcmall...)

On Android we don't use tcmalloc, so we have no protection (just "accidental"
one due to fragmentation on 32 bit)

[Primiano Tucci (use gerrit), 2016-08-03 15:24:37]

Description was changed from

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

BUG=633966,317791
TEST=base_unittests --gtest_filter=OutOfMemory*
==========

to

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

Note also that this CL is just about inducing a hard crash on malloc failure.
This does not change the situation about disallowing large allocations
(>2GB) that might cause int signed/unsigned bugs
(see crbug.com/169327). As things stand today, Android never had that
check and still doesn't yet after this CL.

BUG=633966,317791
TEST=base_unittests --gtest_filter=OutOfMemory*
==========

[Primiano Tucci (use gerrit), 2016-08-03 15:47:28]

The CQ bit was checked by primiano@chromium.org

[commit-bot: I haz the power, 2016-08-03 15:48:31]

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, 2016-08-03 16:31:18]

Description was changed from

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

Note also that this CL is just about inducing a hard crash on malloc failure.
This does not change the situation about disallowing large allocations
(>2GB) that might cause int signed/unsigned bugs
(see crbug.com/169327). As things stand today, Android never had that
check and still doesn't yet after this CL.

BUG=633966,317791
TEST=base_unittests --gtest_filter=OutOfMemory*
==========

to

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

Note also that this CL is just about inducing a hard crash on malloc failure.
This does not change the situation about disallowing large allocations
(>2GB) that might cause int signed/unsigned bugs
(see crbug.com/169327). As things stand today, Android never had that
check and still doesn't yet after this CL.

BUG=633966,317791
TEST=base_unittests --gtest_filter=OutOfMemory*
==========

[commit-bot: I haz the power, 2016-08-03 16:31:19]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-08-03 16:33:29]

Description was changed from

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

Note also that this CL is just about inducing a hard crash on malloc failure.
This does not change the situation about disallowing large allocations
(>2GB) that might cause int signed/unsigned bugs
(see crbug.com/169327). As things stand today, Android never had that
check and still doesn't yet after this CL.

BUG=633966,317791
TEST=base_unittests --gtest_filter=OutOfMemory*
==========

to

==========
android: Enable death on malloc/operator new failure.

1. Historically the OnNoMemory suicide on malloc/new failure was not
enabled on Android. This seems to be due to the fact that
set_new_handler was not avilable on Android back in the days of
pre-libcxx. See crbug.com/317791 .

2. After the libcxx switch, however, the combination of operator new
throwing bad_alloc and chrome building with -fno-exception made
operator new (but not malloc) inadvertently suicidal, by virtue of
ending up calling the default exception handler.
See crbug.com/633313#c28 .

3. crrev.com/1883093005 (first seen in M52) introduced a shim layer
wrapping malloc and operator new, which was intending, among the
various things, to make malloc / new finally secure on Android.
This good intend, however, failed to materialize because the
set_new_handler call in memory_linux.cc was still #ifdef-ed out
on Android. Similarly the memory_unittests.cc were excluded on
Android for the same reason (Android was deemed to not possibly
be secure since 1.).

In summary here's what went wrong:
- When we switched to libcxx, nobody realized that we could have
  finally taken advantage of set_new_handler.
- When I enabled the android shim I didn't realize about the
  missing set_new_handler call. I was assuming that the memory
  tests would have screamed red if I did something wrong, but I
  didn't realize that they were disabled on Android.

This CL fixes all this, enabling set_new_handler on Android and
enabling the tests.

Note also that this CL is just about inducing a hard crash on malloc failure.
This does not change the situation about disallowing large allocations
(>2GB) that might cause int signed/unsigned bugs
(see crbug.com/169327). As things stand today, Android never had that
check and still doesn't yet after this CL.

BUG=633966,317791
TEST=base_unittests --gtest_filter=OutOfMemory*

Committed: https://crrev.com/227dbd3dc564004471f146ef655fad35c52704c3
Cr-Commit-Position: refs/heads/master@{#409531}
==========

[commit-bot: I haz the power, 2016-08-03 16:33:30]

Patchset 4 (id:??) landed as
https://crrev.com/227dbd3dc564004471f146ef655fad35c52704c3
Cr-Commit-Position: refs/heads/master@{#409531}