JDK-8047340 : (process) Runtime.exec() fails in Turkish locale
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 7-pool,8u5
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2014-06-13
  • Updated: 2015-02-02
  • Resolved: 2014-07-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u80Fixed 8u40 b02Fixed
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) 

ADDITIONAL OS VERSION INFORMATION :
Darwin **************************** 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64 

A DESCRIPTION OF THE PROBLEM :
Java 8 switched to using posix_spawn by default to launch external processes on OS X (and other BSD-like systems).  When java is running on a system with a default locale such as Turkish that uses non-ascii characters, this fails with an exception.  The root cause is attempting to convert the lowercase system property to an uppercase enum constant using the default locale (in Turkish, this converts lowercase 'i' to unicode character U+0130) which results in the constant not being found.

REGRESSION.  Last worked in version 7u60

ADDITIONAL REGRESSION INFORMATION: 
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) 

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Set the default locale to e.g. Turkish
2. Use Runtime.exec() to launch an external process


EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
The call to Runtime.exec() should return normally.
ACTUAL -
An exception is thrown.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.Error: posix_spawn is not a supported process launch mechanism on this platform.
	at java.lang.UNIXProcess$1.run(UNIXProcess.java:105)
	at java.lang.UNIXProcess$1.run(UNIXProcess.java:94)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.lang.UNIXProcess.<clinit>(UNIXProcess.java:92)
	at java.lang.ProcessImpl.start(ProcessImpl.java:130)
	at java.lang.ProcessBuilder.start(ProcessBuilder.java:1023)
	at  java.lang.Runtime.exec(Runtime.java:620)
	at java.lang.Runtime.exec(Runtime.java:485)


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class Test {

	public static void main(final String[] args) {
		Locale.setDefault(new Locale("tr", ""));
		try {
			Process exec = Runtime.getRuntime().exec("ls");
		}
		catch (IOException e) {
			e.printStackTrace();
		}
	}

}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Use an alternative locale.


Comments
The bug is reproducible with jdk 7u65 on MacOS. It is nice to have this backported to JDK 7. On 08/18/14 01:48 PM, Uwe Schindler wrote: > Hi Balchandra: > > I checked it out with Java 7 on FreeBSD: > > ==== SNIP ==== > [uschindler@lucene ~]$ cat Test.java > import java.util.Locale; > > public class Test { > > public static void main(final String[] args) throws Exception { > Locale.setDefault(new Locale("tr", "")); > Process exec = Runtime.getRuntime().exec("ls"); > } > > } > > [uschindler@lucene ~]$ javac Test.java > > [uschindler@lucene ~]$ java -version > openjdk version "1.7.0_60" > OpenJDK Runtime Environment (build 1.7.0_60-b19) > OpenJDK 64-Bit Server VM (build 24.60-b09, mixed mode) > [uschindler@lucene ~]$ java Test > Exception in thread "main" java.lang.Error: posix_spawn is not a supported process launch mechanism on this platform. > at java.lang.UNIXProcess$1.run(UNIXProcess.java:111) > at java.lang.UNIXProcess$1.run(UNIXProcess.java:93) > at java.security.AccessController.doPrivileged(Native Method) > at java.lang.UNIXProcess.<clinit>(UNIXProcess.java:91) > at java.lang.ProcessImpl.start(ProcessImpl.java:130) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1022) > at java.lang.Runtime.exec(Runtime.java:617) > at java.lang.Runtime.exec(Runtime.java:450) > at java.lang.Runtime.exec(Runtime.java:347) > at Test.main(Test.java:7) > ==== SNIP ==== > > On MacOSX: > > ==== SNIP ==== > macosx-vm:tmp jenkins$ ~/tools/java/64bit/jdk1.6.0/bin/javac Test.java > > macosx-vm:tmp jenkins$ ~/tools/java/64bit/jdk1.6.0/bin/java -version > java version "1.6.0_65" > Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609) > Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode) > macosx-vm:tmp jenkins$ ~/tools/java/64bit/jdk1.6.0/bin/java Test > > -> So it seems that Apple's JDK6 is immune. Unfortunately I don���t have a FreeBSD version available. I also have no Solaris or AIX one. > > macosx-vm:tmp jenkins$ ~/tools/java/64bit/jdk1.7.0/bin/java -version > java version "1.7.0_65" > Java(TM) SE Runtime Environment (build 1.7.0_65-b17) > Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) > macosx-vm:tmp jenkins$ ~/tools/java/64bit/jdk1.7.0/bin/java Test > Exception in thread "main" java.lang.Error: posix_spawn is not a supported process launch mechanism on this platform. > at java.lang.UNIXProcess$1.run(UNIXProcess.java:104) > at java.lang.UNIXProcess$1.run(UNIXProcess.java:93) > at java.security.AccessController.doPrivileged(Native Method) > at java.lang.UNIXProcess.<clinit>(UNIXProcess.java:91) > at java.lang.ProcessImpl.start(ProcessImpl.java:130) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1028) > at java.lang.Runtime.exec(Runtime.java:617) > at java.lang.Runtime.exec(Runtime.java:450) > at java.lang.Runtime.exec(Runtime.java:347) > at Test.main(Test.java:7) > > macosx-vm:tmp jenkins$ ~/tools/java/64bit/jdk1.8.0/bin/java -version > java version "1.8.0_11" > Java(TM) SE Runtime Environment (build 1.8.0_11-b12) > Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode) > macosx-vm:tmp jenkins$ ~/tools/java/64bit/jdk1.8.0/bin/java Test > Exception in thread "main" java.lang.Error: posix_spawn is not a supported process launch mechanism on this platform. > at java.lang.UNIXProcess$1.run(UNIXProcess.java:105) > at java.lang.UNIXProcess$1.run(UNIXProcess.java:94) > at java.security.AccessController.doPrivileged(Native Method) > at java.lang.UNIXProcess.<clinit>(UNIXProcess.java:92) > at java.lang.ProcessImpl.start(ProcessImpl.java:130) > at java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) > at java.lang.Runtime.exec(Runtime.java:620) > at java.lang.Runtime.exec(Runtime.java:450) > at java.lang.Runtime.exec(Runtime.java:347) > at Test.main(Test.java:7) > ==== SNIP ==== > > Uwe
18-08-2014

Here is the email from Uwe from Apache Lucene/Solr. On 08/17/14 10:08 PM, Uwe Schindler wrote: > Hi, > > it took some time to find out, why sometimes Lucene/Solr's tests failed with a very strange error message when trying to fork a process on MacOSX and Linux. The reason for this bug to appear is our randomized testing framework: As you know, we execute all tests in different settings like default charsets, default locales or default timezones, to find bugs caused by settings applied to the environment, that may affect the code in an incorrect way. For more information, see this (already famous) blog entry: http://blog.thetaphi.de/2012/07/default-locales-default-charsets-and.html > > In our case the JDK issue was: > https://bugs.openjdk.java.net/browse/JDK-8047340 > > The issue on our side: > https://issues.apache.org/jira/browse/SOLR-6387 > > We just want to add, that this bug also applies to Java 7 - the same issue exists there (and possibly also on Java 6). So the fix (Locale.ENGLISH / Locale.ROOT) should be backported to Java 7 and Java 6 for customers with support contract, too. As I cannot modify the bug report, it would be good to add issues for Java 7 and Java 6, too. > > Uwe
18-08-2014

It turned out the real fix to this issue on JDK9 was the fix to 8000975, where it added Locale.ENGLISH to String.toUpperCase() method. That way Lower/UpperCasing I/i (in "POS*I*X_SPAWN") should result in a correct one. Although ideally backporting this changeset to JDK8 update line would be desirable, simply add Locale.ROOT (more appropriate in this case, as this constant is for locale neutral operations) to String.toLower/Uppercase()'s argument should fix this problem.
19-06-2014

Although this is not reproducible with JDK9 (with the fix to the one I mentioned above), it IS still reproducible with 8u20. Will investigate it further.
19-06-2014

Please test with 8u20
19-06-2014

Must be a dup of JDK-8041791
19-06-2014

The workaround for now is to run with -Djdk.lang.Process.launchMechanism=fork until this is resolved.
19-06-2014