Disable regress-crbug-518748. It is failing/flaking on many bots

Disable regress-crbug-518748. It is failing/flaking on many bots

BUG=chromium:518748
TBR=mstarzinger@chromium.org
LOG=n

Committed: https://chromium.googlesource.com/v8/v8/+/8f441181a570c44ef5c949e8dfd9fd326ac10345

[binji, 2015-08-19 17:48:57]

Committed patchset #1 (id:1) manually as
8f441181a570c44ef5c949e8dfd9fd326ac10345 (presubmit successful).

[Michael Starzinger, 2015-08-19 18:25:01]

Is there a plan to make the test more solid in the future? Because if not, then
I would just vote for removing/deleting the regression test. Having it disabled
for an indefinite amount of time doesn't buy us much. I would be fine with
removing/deleting it if investing more time doesn't make sense in this case. Up
to you.

[Michael Starzinger, 2015-08-19 18:26:19]

LGTM for de-flaking of course. :)

[binji, 2015-08-19 18:52:18]

On 2015/08/19 at 18:25:01, mstarzinger wrote:
> Is there a plan to make the test more solid in the future? Because if not,
then I would just vote for removing/deleting the regression test. Having it
disabled for an indefinite amount of time doesn't buy us much. I would be fine
with removing/deleting it if investing more time doesn't make sense in this
case. Up to you.

Yeah, I can't really think of a way to make this more robust. It doesn't seem
possible to know whether creating a new thread will have enough memory ahead of
time, so all I can do is play with the worker limit.

[Michael Starzinger, 2015-08-19 18:52:55]

On 2015/08/19 18:52:18, binji wrote:
> On 2015/08/19 at 18:25:01, mstarzinger wrote:
> > Is there a plan to make the test more solid in the future? Because if not,
> then I would just vote for removing/deleting the regression test. Having it
> disabled for an indefinite amount of time doesn't buy us much. I would be fine
> with removing/deleting it if investing more time doesn't make sense in this
> case. Up to you.
> 
> Yeah, I can't really think of a way to make this more robust. It doesn't seem
> possible to know whether creating a new thread will have enough memory ahead
of
> time, so all I can do is play with the worker limit.

Nah, let's just remove the test then.