JDK-7151434 : java -jar -XX crashes java launcher
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 8
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-03-06
  • Updated: 2013-08-02
  • Resolved: 2012-05-18
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.
7u40Fixed 8 b38Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
The java launcher crashes in JLI_WildcardExpandClasspath when run with the (strange) command line "java -jar -XX"

$ /localhome/java/jdk-8-ea-bin-b28/bin/java -jar -XX
Segmentation fault

Linux stack trace:
$ gdb --args /localhome/java/jdk-8-ea-bin-b28/fastdebug/bin/java -jar -XX
(gdb) r
Starting program: /localhome/java/jdk-8-ea-bin-b28/fastdebug/bin/java -jar -XX
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
__strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:33
33	../sysdeps/x86_64/multiarch/../strchr.S: No such file or directory.
	in ../sysdeps/x86_64/multiarch/../strchr.S
(gdb) bt
#0  __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:33
#1  0x00007ffff79b0e9f in JLI_WildcardExpandClasspath ()
   from /localhome/java/jdk-8-ea-bin-b28/fastdebug/bin/../jre/lib/amd64/jli/libjli.so
#2  0x00007ffff79ac8ac in SetClassPath ()
   from /localhome/java/jdk-8-ea-bin-b28/fastdebug/bin/../jre/lib/amd64/jli/libjli.so
#3  0x00007ffff79acdc6 in JLI_Launch ()
   from /localhome/java/jdk-8-ea-bin-b28/fastdebug/bin/../jre/lib/amd64/jli/libjli.so
#4  0x0000000000400676 in main ()

The crash reproduces on solaris-amd64 as well.

I can reproduce this on JDK7 b147 but not on JDK6u29 b11, so I guess this is something that was introduced in 7.

EVALUATION ParseArguments in java.c will set "what" (pwhat) to null as it interprets the next value (jar name) as an argument since it is prefixed by a "-". The JLI_WildcardExpandClasspath needs to have a null check.