New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java executor deadlock #53

Closed
Xyene opened this Issue Jun 3, 2015 · 15 comments

Comments

Projects
None yet
2 participants
@Xyene
Member

Xyene commented Jun 3, 2015

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.

@Xyene Xyene self-assigned this Jun 3, 2015

@quantum5

This comment has been minimized.

Member

quantum5 commented Jun 3, 2015

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

This comment has been minimized.

Member

quantum5 commented Jun 3, 2015

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

@Xyene

This comment has been minimized.

Member

Xyene commented Jun 3, 2015

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

This comment has been minimized.

Member

Xyene commented Jun 3, 2015

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

@Xyene

This comment has been minimized.

Member

Xyene commented Jun 4, 2015

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

This comment has been minimized.

Member

Xyene commented Jun 4, 2015

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

@quantum5

This comment has been minimized.

Member

quantum5 commented Jun 4, 2015

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

This comment has been minimized.

Member

Xyene commented Jun 4, 2015

@quantum5

This comment has been minimized.

Member

quantum5 commented Jun 4, 2015

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

This comment has been minimized.

Member

quantum5 commented Jun 4, 2015

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

This comment has been minimized.

Member

quantum5 commented Jun 4, 2015

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

@quantum5

This comment has been minimized.

Member

quantum5 commented Jun 4, 2015

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

This comment has been minimized.

Member

quantum5 commented Jun 4, 2015

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

This comment has been minimized.

Member

Xyene commented Jun 4, 2015

@quantum5

This comment has been minimized.

Member

quantum5 commented Jan 12, 2016

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

@quantum5 quantum5 closed this Jan 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment