-
Bug
-
Resolution: Duplicate
-
P3
-
None
-
17
-
x86_64
-
os_x
ADDITIONAL SYSTEM INFORMATION :
macOS 15.1.1 (24B91)
Apple M3 (ARM)
openjdk version "17.0.13" 2024-10-15 LTS
OpenJDK Runtime Environment Zulu17.54+21-CA (build 17.0.13+11-LTS)
OpenJDK 64-Bit Server VM Zulu17.54+21-CA (build 17.0.13+11-LTS, mixed mode, sharing)
(also tested and confirmed issue with Adoptium OpenJDK)
(also tested and confirmed with OpenJDK 21)
A DESCRIPTION OF THE PROBLEM :
If a process is started from a Java app that is run from within the macOS App Sandbox (https://developer.apple.com/documentation/xcode/configuring-the-macos-app-sandbox), the Java program will hang for a few minutes before successfully running the process. For example, the provided Java code should just open Finder. If you compile that into a jar file and use a macOS sandboxed app to execute the java file (e.g. `java -jar /path/to/file.jar`), it will hang for several minutes before finally opening Finder.
I do understand that this may be a macOS issue, and also intend to report the issue to Apple.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile a jar file with the provided code.
2. Build a native macOS app that has App Sandbox enabled that runs the jar file. For example, something like this code in Swift:
```
let jarURL = Bundle.main.url(forResource: "JavaProcessBuilder", withExtension: "jar")
let javaURL = URL(filePath: "/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/bin/java")
let process = Process()
process.executableURL = javaURL
process.arguments = ["-jar", jarURL!.path]
try? process.run()
process.waitUntilExit()
```
3. Run the app.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Finder opens almost instantly.
ACTUAL -
Java hangs for up to several minutes.
During this time, you can see a child process was launched called `jspawnhelper`. Using a debugger, I found that `jspawnhelper` was stuck during a call to the `close` C function. From looking at the source code, I believe the relevant line is at https://github.com/openjdk/jdk/blob/1a07d542ec810282eb78653698d098a24b35686f/src/java.base/unix/native/jspawnhelper/jspawnhelper.c#L183 and linked to the fix for the bug https://bugs.openjdk.org/browse/JDK-8307990. If I revert to an older OpenJDK before that fix (such as 17.0.10), I can no longer reproduce the issue.
---------- BEGIN SOURCE ----------
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
public class Main {
public static void main(String[] args) {
ProcessBuilder builder = new ProcessBuilder();
List<String> cmd = new ArrayList<>();
cmd.add("/usr/bin/open");
cmd.add("-aFinder");
builder.command(cmd);
try {
builder.start();
} catch (IOException e) {
System.out.println("Process failed to start: " + e.getLocalizedMessage());
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Downgrade to a version of Java without the fix to https://bugs.openjdk.org/browse/JDK-8307990, or disable App Sandbox.
FREQUENCY : always
macOS 15.1.1 (24B91)
Apple M3 (ARM)
openjdk version "17.0.13" 2024-10-15 LTS
OpenJDK Runtime Environment Zulu17.54+21-CA (build 17.0.13+11-LTS)
OpenJDK 64-Bit Server VM Zulu17.54+21-CA (build 17.0.13+11-LTS, mixed mode, sharing)
(also tested and confirmed issue with Adoptium OpenJDK)
(also tested and confirmed with OpenJDK 21)
A DESCRIPTION OF THE PROBLEM :
If a process is started from a Java app that is run from within the macOS App Sandbox (https://developer.apple.com/documentation/xcode/configuring-the-macos-app-sandbox), the Java program will hang for a few minutes before successfully running the process. For example, the provided Java code should just open Finder. If you compile that into a jar file and use a macOS sandboxed app to execute the java file (e.g. `java -jar /path/to/file.jar`), it will hang for several minutes before finally opening Finder.
I do understand that this may be a macOS issue, and also intend to report the issue to Apple.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Compile a jar file with the provided code.
2. Build a native macOS app that has App Sandbox enabled that runs the jar file. For example, something like this code in Swift:
```
let jarURL = Bundle.main.url(forResource: "JavaProcessBuilder", withExtension: "jar")
let javaURL = URL(filePath: "/Library/Java/JavaVirtualMachines/zulu-17.jdk/Contents/Home/bin/java")
let process = Process()
process.executableURL = javaURL
process.arguments = ["-jar", jarURL!.path]
try? process.run()
process.waitUntilExit()
```
3. Run the app.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Finder opens almost instantly.
ACTUAL -
Java hangs for up to several minutes.
During this time, you can see a child process was launched called `jspawnhelper`. Using a debugger, I found that `jspawnhelper` was stuck during a call to the `close` C function. From looking at the source code, I believe the relevant line is at https://github.com/openjdk/jdk/blob/1a07d542ec810282eb78653698d098a24b35686f/src/java.base/unix/native/jspawnhelper/jspawnhelper.c#L183 and linked to the fix for the bug https://bugs.openjdk.org/browse/JDK-8307990. If I revert to an older OpenJDK before that fix (such as 17.0.10), I can no longer reproduce the issue.
---------- BEGIN SOURCE ----------
import java.io.IOException;
import java.util.ArrayList;
import java.util.List;
public class Main {
public static void main(String[] args) {
ProcessBuilder builder = new ProcessBuilder();
List<String> cmd = new ArrayList<>();
cmd.add("/usr/bin/open");
cmd.add("-aFinder");
builder.command(cmd);
try {
builder.start();
} catch (IOException e) {
System.out.println("Process failed to start: " + e.getLocalizedMessage());
}
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Downgrade to a version of Java without the fix to https://bugs.openjdk.org/browse/JDK-8307990, or disable App Sandbox.
FREQUENCY : always
- duplicates
-
JDK-8343285 java.lang.Process is unresponsive and CPU usage spikes to 100%
-
- Resolved
-
- relates to
-
JDK-8307990 jspawnhelper must close its writing side of a pipe before reading from it
-
- Closed
-
-
JDK-8324577 [REDO] - [IMPROVE] OPEN_MAX is no longer the max limit on macOS >= 10.6 for RLIMIT_NOFILE
-
- Resolved
-