[BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java

Adam Farley8 adam.farley at uk.ibm.com
Wed Aug 23 18:51:11 UTC 2017


Hi Thomas,

First, thank you for your time. :)

The exit hook you recommend sounds like a fine workaround, though I 
suggest a return code would make a better long term solution.

Especially if the exit hook might be broken. :)

I don't think we can expect new JNI users to be familiar with the exit 
hook, and having Java designed to use the nuclear option (exit(0)) for a 
mere help option seems like overkill.

>From what you're saying, I think you're agreeing that it's better to pass 
a negative return code than call exit(#) and catch it, so that the VM can 
shut down "cleanly" instead of being suddenly terminated by a random chunk 
of internal c code.

Does this sound correct?

Best Regards

Adam Farley

P.S I should note that, if we agree to go ahead with the negative return 
code, we'll need to modify java.c to ignore it. IMO: Help options should 
only return negative return codes to JNI callers, not java executable 
users.




From:   Thomas Stüfe <thomas.stuefe at gmail.com>
To:     Adam Farley8 <adam.farley at uk.ibm.com>
Cc:     Java Core Libs <core-libs-dev at openjdk.java.net>
Date:   23/08/2017 18:45
Subject:        Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM 
can be exited by java



Hi Adam,

would the JNI exit hook not solve your problem (JavaVMOption "exit")? One 
could use it to intercept any exit(2) calls.

However, I am not sure it always fires, and if it does not, whether this 
should be considered a bug. The official JNI documentation is pretty 
sparse (
http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/invocation.html
). 

Another thing, even if one catches ::exit(), if the VM creation failed the 
process can be in an undefined state, because I am not sure we clean up 
orderly for every error exit. So, e.g., signal handlers may still be 
installed etc.

Kind Regards, Thomas 




On Wed, Aug 23, 2017 at 5:54 PM, Adam Farley8 <adam.farley at uk.ibm.com> 
wrote:
Hi All,

Problem: Several of Java's "c" files call exit(0) if you pass certain
command-line options to JNI_CreateJavaVM, which can terminate the C++ code
JNI users use to initialise the JVM.

Example: If you write some C++ code that calls JNI_CreateJavaVM, and uses
the option "-agentlib:jdwp=help", Java's c files will print the needed
help output and call exit(0).

Result: Your C++ code is terminated on this line, and a return code of 0
is produced.

Issues:

Issue 1: The exit(0) prevents your code from doing anything useful after
the JNI_CreateJavaVM call.
Issue 2: The exit(0) indicates to anything monitoring your C++ code that
your code exited normally, even though it was terminated mid-way-through.
Issue 3: This return code is useless to us, as a 0 can indicate the VM
started correctly, or it can indicate the VM was terminated due to one or
more of these command-line options.
Issue 4: Of the other JNI return values (JNI_OK, JNI_ERR, etc) none of
them appear to cover this scenario.


Proposed solutions:

PS1: We should amend the JNI specification to include a "JNI_SILENT_EXIT"
return code, so the C++ code knows a VM was not created, but that it isn't
an error.
PS2: We should identify a list of the command-line options that produce
this behaviour via the JNI. (not all of the "help" options are recognised
by the JNI interface. E.g. -version and -help produce a JNI_ERR and an
"Option not recognised" message)
PS3: We should replace these annoying exit(0) calls with code that returns
"JNI_SILENT_EXIT", so the C++ code has a chance to finish.


Best Regards

Adam Farley
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU



Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


More information about the core-libs-dev mailing list