Java executor deadlock

[Xyene]

On Excalibur and Durandal, a user submission for DMPG '15 S5 - Black and White murders the Java executor with an infinitely long grading time.

root@onlinejudge2:~# java -version
java version "1.7.0_65"
OpenJDK Runtime Environment (IcedTea 2.5.1) (7u65-2.5.1-5~deb7u1)
OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode)

root@onlinejudge2:~# uname -a
Linux onlinejudge2 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux

The offending submission:

import java.io.*;
import java.util.*;

public class S5
{
   public static void main (String[] args)
   {
      try
      {
         int n =0, m = 0;

         int[] x = new int[m];
         int[] y = new int[m];
         int[] w = new int[m];
         int[] h = new int[m];

         boolean[][] cells;
         BufferedReader br = new BufferedReader (new InputStreamReader(System.in));

         String temp = "";
         temp = br.readLine();
         n = Integer.parseInt(temp.split(" ")[0]);
         cells = new boolean[n][n];
         m = Integer.parseInt(temp.split(" ")[1]);
         x = new int[m];
         y = new int[m];
         w = new int[m];
         h = new int[m];
         for (int i = 0; i < m; i++)
         {

            temp = br.readLine();
            x[i] = Integer.parseInt(temp.split(" ")[0]);
            y[i] = Integer.parseInt(temp.split(" ")[1]);
            w[i] = Integer.parseInt(temp.split(" ")[2]);
            h[i] = Integer.parseInt(temp.split(" ")[3]);
         }


         for (int i = 0; i < n; i++)
         {
            for (int k = 0; k <n; k++)
            {
               cells[i][k] = false;
            }

         }

         for (int com = 0; com < m; com++)
         {
            for (int i = x[com]; i < (x[com] + w[com]); i++)
            {
               for (int k = y[com]; k <y[com] + h[com]; k++)
               {
                  cells[i][k] = !cells[i][k];
               }
            }
         }

         int count = 0;

         for (int i = 0; i < n; i++)
         {
            for (int k = 0; k < n; k++)
            {
               if (cells[i][k] == true)
               {
                  count++;
               }
            }
         }

         System.out.println(count);
      }
      catch (IOException ioe)
      {
      }
   }

}

Submission abortion continues to work, however.

[quantum5]

I suspect a regression in the OpenJDK JIT compiler in that version. Other judges use 7u79. Then again the other available judges are all 32-bit...

[quantum5]

Will confirm tomorrow by deploying a 64-bit judge VM.

[Xyene]

Submission 95719 succeeds in deadlocking a completely different case.

It would appear that input must be consumed for the issue to manifest, though it may just be a timing thing.

[Xyene]

I'm hesitant to rule this issue out as an OpenJDK bug.

[Xyene]

After about 30 minutes, the judge indeed crashes.

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (safepoint.cpp:321), pid=2932, tid=140068389676800
# guarantee(PageArmed == 0) failed: invariant
#
# JRE version: OpenJDK Runtime Environment (7.0_65-b32) (build 1.7.0_65-b32)
# Java VM: OpenJDK 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /tmp/tmpYjaHIu/hs_err_pid2932.log
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#

[Xyene]

According to @quantum5 the state file is successfully written, but the judge fails to exit.

[quantum5]

quantum@astatine:/tmp/tmpVUlScY$ cat state
1236 0 35812 0 0 OK
quantum@astatine:/tmp/tmpVUlScY$ ps aux | grep java
judge    23308 82.0 32.7 1230564 165568 ?      Sl   20:49   3:09 java -client -Xmx262144K -jar /home/quantum/judge/executors/java_executor.jar /tmp/tmpVUlScY S5 4000 state

[Xyene]

Never thought System.exit could fail: https://github.com/DMOJ/judge/blob/master/java_executor/src/ca/dmoj/java/JavaSafeExecutor.java#L115

[quantum5]

quantum@astatine:/tmp/tmpVUlScY$ sudo jstack 23308
23308: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding
quantum@astatine:/tmp/tmpVUlScY$ sudo jstack -F 23308
Attaching to process ID 23308, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.79-b02
Deadlock Detection:

No deadlocks found.

Thread 23319: (state = IN_JAVA)
 - S5.main(java.lang.String[]) @bci=387, line=80 (Compiled frame; information may be imprecise)
 - sun.reflect.NativeMethodAccessorImpl.invoke0(java.lang.reflect.Method, java.lang.Object, java.lang.Object[]) @bci=0 (Interpreted frame)
 - sun.reflect.NativeMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=87, line=57 (Interpreted frame)
 - sun.reflect.DelegatingMethodAccessorImpl.invoke(java.lang.Object, java.lang.Object[]) @bci=6, line=43 (Interpreted frame)
 - java.lang.reflect.Method.invoke(java.lang.Object, java.lang.Object[]) @bci=57, line=606 (Interpreted frame)
 - ca.dmoj.java.SubmissionThread.run() @bci=54, line=27 (Interpreted frame)


Thread 23318: (state = BLOCKED)
 - java.lang.Thread.sleep(long) @bci=0 (Interpreted frame)
 - ca.dmoj.java.ShockerThread.run() @bci=4, line=22 (Interpreted frame)


Thread 23313: (state = BLOCKED)


Thread 23312: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=135 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2, line=151 (Interpreted frame)
 - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 (Interpreted frame)


Thread 23311: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - java.lang.ref.Reference$ReferenceHandler.run() @bci=46, line=133 (Interpreted frame)


Thread 23309: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Thread.join(long) @bci=38, line=1281 (Interpreted frame)
 - java.lang.Thread.join() @bci=2, line=1355 (Interpreted frame)
 - ca.dmoj.java.JavaSafeExecutor.main(java.lang.String[]) @bci=319, line=173 (Interpreted frame)

[quantum5]

OK the state file is from the previous test case:

Batch #2 (0/30 points)
Case #1:    WA  [1.236s,    34.97 MB]

1236 0 35812 0 0 OK

[quantum5]

The offending line seems to be System.out.println(7500);, but println is not in the stacktrace.

[quantum5]

Running the test case on plain java, no fancy executor:

quantum@astatine:/tmp/tmpVUlScY$ jstack -F 23978
Attaching to process ID 23978, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 24.79-b02
Deadlock Detection:

No deadlocks found.

Thread 23983: (state = BLOCKED)


Thread 23982: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=135 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2, line=151 (Interpreted frame)
 - java.lang.ref.Finalizer$FinalizerThread.run() @bci=36, line=209 (Interpreted frame)


Thread 23981: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.Object.wait() @bci=2, line=503 (Interpreted frame)
 - java.lang.ref.Reference$ReferenceHandler.run() @bci=46, line=133 (Interpreted frame)


Thread 23979: (state = IN_JAVA)
 - S5.main(java.lang.String[]) @bci=387, line=80 (Compiled frame; information may be imprecise)

You know you are screwed when SIGTERM doesn't kill the JVM after this.

[quantum5]

Worth noting that the submission is very far from actually finishing. The snapshot is taken a couple of seconds in, when the same submission is still busy in the toggling loop when run on the oracle java 8 vm and another computer. The idea of execution at line 80 seems impossible.

[Xyene]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2397#c0

[quantum5]

I think I will close this one, as it is confirmed bug in the JRE.