-
Bug
-
Resolution: Won't Fix
-
P3
-
17.0.3, 17.0.5, 19, 20
-
x86_64
-
linux_ubuntu
ADDITIONAL SYSTEM INFORMATION :
Arch: x86_64
OS: Ubuntu 20.04.4 LTS
Memory: 16G
CPU: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
HotSpot
- openjdk version "17.0.5-internal" 2022-10-18
- OpenJDK Runtime Environment (build 17.0.5-internal+0-adhoc.congli.jdk17u-dev)
- OpenJDK 64-Bit Server VM (build 17.0.5-internal+0-adhoc.congli.jdk17u-dev, mixed mode, sharing)
-
- IMPLEMENTOR="N/A"
- JAVA_VERSION="17.0.5"
- JAVA_VERSION_DATE="2022-10-18"
- LIBC="gnu"
- MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.incubator.foreign jdk.incubator.vector jdk.internal.le jdk.internal.opt jdk.internal.vm.ci jdk.internal.vm.compiler jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.nio.mapmode jdk.random jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
- OS_ARCH="x86_64"
- OS_NAME="Linux"
- SOURCE=".:git:6f4c27006d75"
A DESCRIPTION OF THE PROBLEM :
Problem: If you run the following test on a relatively low-memory (16G; this is indeed not low at all) machine, the process will be **quickly killed** by the operating system. However, if you disable JIT compilation (using `-Xint` option), the program will definitely **normally exit** if you give it sufficient time (~20min; depends on your machine).
Diagnosis: This happens perhaps because the generated machine code keeps allocating more and more native memory without any free operations.
**Note**
1. The given test may take **~1min** to be killed. So please be patient.
2. The problem was found in the repo https://github.com/openjdk/jdk17u-dev (commit 6f4c27006d75), OpenJDK 17.0.5 (internal).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. javac Test.java
2. java [-Xbatch] Test # you can also remove -Xbatch but sometimes takes longer to be killed
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Exit normally
ACTUAL -
The process is killed by the operating system
---------- BEGIN SOURCE ----------
import java.util.zip.ZipOutputStream;
import java.io.ByteArrayOutputStream;
import java.util.zip.GZIPOutputStream;
import java.util.zip.ZipEntry;
// Generated by Java* Fuzzer test generator (1.0.001). Wed Jun 29 19:04:03 2022
public class Test {
public static void main(String[] strArr) {
for (int ax$122 = 0; ax$122 < 10; ax$122 += 1) {
for (int ax$1112 = 1; ax$1112 < 197; ax$1112 += 1) {
for (int ax$11 = -4910; ax$11 < 314; ax$11 += 1) {
try {
boolean ax$7 = false;
byte[] ax$3 = new byte[1 << 14];
try (ByteArrayOutputStream ax$8 = new ByteArrayOutputStream();
ZipOutputStream ax$9 = new ZipOutputStream(ax$8)) {
final byte[] ax$4 = { 'x' };
ax$9.putNextEntry(new ZipEntry("a.gz"));
GZIPOutputStream ax$5 = new GZIPOutputStream(ax$9);
ax$5.write(ax$4);
ax$5.finish();
if (ax$7)
ax$9.write(ax$4);
ax$9.closeEntry();
ax$9.putNextEntry(new ZipEntry("b.gz"));
GZIPOutputStream ax$6 = new GZIPOutputStream(ax$9);
ax$6.write(ax$4);
ax$6.finish();
ax$9.closeEntry();
ax$9.flush();
ax$3 = ax$8.toByteArray();
}
} catch (Throwable ax$10) {
}
}
System.out.println("loop: " + ax$1112);
}
}
}
}
---------- END SOURCE ----------
FREQUENCY : always
Arch: x86_64
OS: Ubuntu 20.04.4 LTS
Memory: 16G
CPU: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz
HotSpot
- openjdk version "17.0.5-internal" 2022-10-18
- OpenJDK Runtime Environment (build 17.0.5-internal+0-adhoc.congli.jdk17u-dev)
- OpenJDK 64-Bit Server VM (build 17.0.5-internal+0-adhoc.congli.jdk17u-dev, mixed mode, sharing)
-
- IMPLEMENTOR="N/A"
- JAVA_VERSION="17.0.5"
- JAVA_VERSION_DATE="2022-10-18"
- LIBC="gnu"
- MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.incubator.foreign jdk.incubator.vector jdk.internal.le jdk.internal.opt jdk.internal.vm.ci jdk.internal.vm.compiler jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jpackage jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.rmi jdk.net jdk.nio.mapmode jdk.random jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
- OS_ARCH="x86_64"
- OS_NAME="Linux"
- SOURCE=".:git:6f4c27006d75"
A DESCRIPTION OF THE PROBLEM :
Problem: If you run the following test on a relatively low-memory (16G; this is indeed not low at all) machine, the process will be **quickly killed** by the operating system. However, if you disable JIT compilation (using `-Xint` option), the program will definitely **normally exit** if you give it sufficient time (~20min; depends on your machine).
Diagnosis: This happens perhaps because the generated machine code keeps allocating more and more native memory without any free operations.
**Note**
1. The given test may take **~1min** to be killed. So please be patient.
2. The problem was found in the repo https://github.com/openjdk/jdk17u-dev (commit 6f4c27006d75), OpenJDK 17.0.5 (internal).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. javac Test.java
2. java [-Xbatch] Test # you can also remove -Xbatch but sometimes takes longer to be killed
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Exit normally
ACTUAL -
The process is killed by the operating system
---------- BEGIN SOURCE ----------
import java.util.zip.ZipOutputStream;
import java.io.ByteArrayOutputStream;
import java.util.zip.GZIPOutputStream;
import java.util.zip.ZipEntry;
// Generated by Java* Fuzzer test generator (1.0.001). Wed Jun 29 19:04:03 2022
public class Test {
public static void main(String[] strArr) {
for (int ax$122 = 0; ax$122 < 10; ax$122 += 1) {
for (int ax$1112 = 1; ax$1112 < 197; ax$1112 += 1) {
for (int ax$11 = -4910; ax$11 < 314; ax$11 += 1) {
try {
boolean ax$7 = false;
byte[] ax$3 = new byte[1 << 14];
try (ByteArrayOutputStream ax$8 = new ByteArrayOutputStream();
ZipOutputStream ax$9 = new ZipOutputStream(ax$8)) {
final byte[] ax$4 = { 'x' };
ax$9.putNextEntry(new ZipEntry("a.gz"));
GZIPOutputStream ax$5 = new GZIPOutputStream(ax$9);
ax$5.write(ax$4);
ax$5.finish();
if (ax$7)
ax$9.write(ax$4);
ax$9.closeEntry();
ax$9.putNextEntry(new ZipEntry("b.gz"));
GZIPOutputStream ax$6 = new GZIPOutputStream(ax$9);
ax$6.write(ax$4);
ax$6.finish();
ax$9.closeEntry();
ax$9.flush();
ax$3 = ax$8.toByteArray();
}
} catch (Throwable ax$10) {
}
}
System.out.println("loop: " + ax$1112);
}
}
}
}
---------- END SOURCE ----------
FREQUENCY : always