This repros with reducing the memory limits:
ulimit -Sv 1000000
/usr/local/google/home/machenbach/v8/v8/out.gn/x64.release/d8 --abort_on_stack_overflow --expose-gc --allow-natives-syntax --invoke-weak-callbacks --omit-quit --es-staging --random-seed 732681078 --ignition --turbo --always-opt /usr/local/google/home/machenbach/v8/v8/out.gn/x64.release/v8_mock.js /usr/local/google/home/machenbach/v8/v8/out.gn/x64.release/v8_suppressions.js ./repro.js

Return code:
echo $?
134

The problem seems to be in the printing in d8:
#2  0x00007ffff7710535 in __gnu_cxx::__verbose_terminate_handler () at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#3  0x00007ffff770e6d6 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:38
#4  0x00007ffff770e703 in std::terminate () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5  0x00007ffff770e922 in __cxxabiv1::__cxa_throw (obj=0x5555562977d0, tinfo=0x7ffff7996b20 <typeinfo for std::bad_alloc>, 
    dest=0x7ffff770cdd0 <std::bad_alloc::~bad_alloc()>) at ../../../../src/libstdc++-v3/libsupc++/eh_throw.cc:87
#6  0x00007ffff770ee0d in operator new (sz=167772163) at ../../../../src/libstdc++-v3/libsupc++/new_op.cc:56
#7  0x00007ffff770eea9 in operator new[] (sz=<optimized out>) at ../../../../src/libstdc++-v3/libsupc++/new_opv.cc:32
#8  0x00005555556605ec in v8::String::Utf8Value::Utf8Value(v8::Local<v8::Value>) ()
#9  0x0000555555635cfb in v8::WriteToFile(_IO_FILE*, v8::FunctionCallbackInfo<v8::Value> const&) ()
#10 0x0000555555635dc9 in v8::Shell::Print(v8::FunctionCallbackInfo<v8::Value> const&) ()

Higher prio as this seems to require patching V8 (not D8) code, e.g.:
diff --git a/src/allocation.h b/src/allocation.h
index 36019d9ab3..0c5d717c5b 100644
--- a/src/allocation.h
+++ b/src/allocation.h
@@ -43,7 +43,7 @@ class AllStatic {

template <typename T>
T* NewArray(size_t size) {
-  T* result = new T[size];
+  T* result = new(std::nothrow) T[size];
  if (result == NULL) FatalProcessOutOfMemory("NewArray");
  return result;
}

First suspected the latest clang roll, but it repros still with:
diff --git a/DEPS b/DEPS
index a52097cdd2..0c5dc4ac78 100644
--- a/DEPS
+++ b/DEPS
@@ -38,7 +38,7 @@ deps = {
   "v8/test/test262/harness":
     Var("chromium_url") + "/external/github.com/test262-utils/test262-harness-py.git" + "@" + "0f2acdd882c84cff43b9d60df7574a1901e2cdcd",
   "v8/tools/clang":
-    Var("chromium_url") + "/chromium/src/tools/clang.git" + "@" + "9fbab72bff9a5f64b32cfab0b131a153cd362b47",
+    Var("chromium_url") + "/chromium/src/tools/clang.git" + "@" + "5c4f541ef78951452780e0ef794c34d867cd8c22",
   "v8/test/wasm-js":
     Var("chromium_url") + "/external/github.com/WebAssembly/spec.git" + "@" + "002e57c86ccf5c80db0de6e40246665340350c43",
 }

Maybe the jessie sysroot change?

Re 4: No, at least my repro reaches minimum two months back. I think there's no point bisecting further, we should just fix it.

+ V8 memory sheriffs: Guess this should go into memory triage?

The troubling part is

  print("v8-foozzie source: /v8/test/mjsunit/regress/regress-500980.js");
  try {
  __v_0 = "__v_0";
  assertThrows(function() { while (true) __v_0 += __v_0; }, RangeError);
  assertThrows(function() { __v_0 in __v_0; }, TypeError);
  } catch(e) { print("Caught: " + e); }
  try {
  print(__PrettyPrint(__v_0));
  } catch(e) { print("Caught: " + e); }

We are concatenating strings until we hit the RangeError and then try to allocate a new backing store for the Utf8Value when printing the string. We run OOM when allocating the new backing store.

With ulimit set to 1GB I am able to trigger this case. The limit doesn't make too much sense though as regular v8 expects to grow until 1.4GB on 64bit. 

At least the repro is expected. The bot could also run OOM if it has only very little physical memory, or is overloaded. Did this test every work on the bots?

The test like this is a fuzzer product. Not sure if it should work. If we don't care, I could suppress output like this.

This test case also doesn't reproduce reliably on the fuzzer bots. They don't set ulimit, so I guess they run out of physical memory.

There's a similar  issue 706548  that repros reliably.

We have several similar issues like this regularly now, like:
https://clusterfuzz.com/v2/testcase-detail/4817699340550144?noredirect=1
https://clusterfuzz.com/v2/testcase-detail/5204056277778432?noredirect=1
https://clusterfuzz.com/v2/testcase-detail/6379332940595200?noredirect=1

I'll add these stacks to the suppressions to reduce the noise. Like that, at least the fuzzer will treat this output like ordinary crashes. Keeping it open what to do with the underlying fundamental problem.

The following revision refers to this bug:
  https://chromium.googlesource.com/v8/v8.git/+/35eb7fb9fbeba7f721251a9f114a4942d7418daa

commit 35eb7fb9fbeba7f721251a9f114a4942d7418daa
Author: Michael Achenbach <machenbach@chromium.org>
Date: Tue Apr 11 12:12:09 2017

[foozzie] Suppress C stack traces.

Bug:  chromium:705962 
NOTRY=true

Change-Id: I734df88af104a9e9800600fee7f41cee5a128450
Reviewed-on: https://chromium-review.googlesource.com/474031
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44566}
[modify] https://crrev.com/35eb7fb9fbeba7f721251a9f114a4942d7418daa/tools/foozzie/v8_suppressions.py

ClusterFuzz testcase 6690617959907328 is flaky and no longer reproduces, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.