<p>Has anyone been able to consistently replicate SIGSEGVs on the JRE using different hardware and different JRE versions? Note (potentially a big note): I am running the process in a Docker container deployed on Kubernetes.</p>

<p>Sample error:</p>

<pre><code># A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fea64dd9d01, pid=21, tid=0x00007fe8dfbfb700
#
# JRE version: Java(TM) SE Runtime Environment (8.0_191-b12) (build 1.8.0_191-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.191-b12 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# J 8706 C2 com.fasterxml.jackson.core.json.ReaderBasedJsonParser.nextFieldName()Ljava/lang/String; (493 bytes) @ 0x00007fea64dd9d01 [0x00007fea64dd9b60+0x1a1]
</code></pre>

<p>I'm currently managing a high I/O process that has many threads doing I/O and serialization: downloading CSVs and JSONs, reading CSVs, writing JSONs into CSVs, and loading CSVs into MySQL. I do this thousands of times during the application's run cycle. I use nothing but commonly-used libraries (Jackson, jOOQ) and "normal" code: specifically, I did not write custom code that uses the JNI. </p>

<p>Without fail, the JVM will SIGSEGV during each run cycle. It seems to SIGSERV in various parts of the code base, but never on a GC thread or any other well-known threads. The "problematic frame" is always compiled code.</p>

<p>Testing specs:</p>

<ul>
<li>Multiple different hardware instances in AWS.</li>
<li>Tested using Java 8 191 and 181. Ubuntu 16.04. </li>
<li>This process is running in a container (Docker) and deployed on Kubernetes.</li>
<li>Docker version: <code>17.03.2-ce</code> </li>
</ul>

<p>Here's the full log:
<a href="https://gist.github.com/navkast/9c95f56ce818d76276684fa5bb9a6864" rel="nofollow noreferrer">https://gist.github.com/navkast/9c95f56ce818d76276684fa5bb9a6864</a></p>

navkast
<p>From the full log:</p>

<blockquote>
  <p>siginfo: si_signo: 11 (SIGSEGV), si_code: 0 (SI_USER)</p>
</blockquote>

<p>This means a <code>kill()</code> was issued. This is not a JVM issue. Something is killing the process deliberately. Probably due to running out of memory.</p>
