Crash JVM

[pinto]

hi all,
I was asked by an interviewer as to how to crash a JVM.If any of
you know abt it let me know.

 

[Thomas Fritsch]

hi all,
I was asked by an interviewer as to how to crash a JVM.If any of
you know abt it let me know.

It is quite easy by loading a library with some self-written JNI-code.
But giving this answer, encourages the interviewer for further questions
about JNI. So be well-prepared...

 

[Daniel Dyer]

hi all,
I was asked by an interviewer as to how to crash a JVM.If any of
you know abt it let me know.

Strange question, I'm sure it would depend on the particular JVM
implementation, but badly behaved JNI code is good way to **** things up.

Dan.

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

hi all,
I was asked by an interviewer as to how to crash a JVM.If any of
you know abt it let me know.

JNI is what we usually do I have also been able to crash the JVM by
feeding it some slightly illegal bytecode with the help of the JVMTI
interface which I was using for some dynamic bytecode modification. The
JVMTI interface is part of the JVM, so I guess this counts as *really*
crashing the JVM.

 

[Chris Uppal]

JNI is what we usually do

I've found JNI to be completely satisfactory for these purposes also...

I have also been able to crash the JVM by
feeding it some slightly illegal bytecode with the help of the JVMTI
interface which I was using for some dynamic bytecode modification.

Interesting. I'd have expected that the byte-code verification would have
eliminated "crash-me" sequences. Perhaps the verifier isn't run on bytecode
injected via the debugging interfaces ?

-- chris

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

Daniel Sjöblom wrote:

Interesting. I'd have expected that the byte-code verification would have
eliminated "crash-me" sequences. Perhaps the verifier isn't run on bytecode
injected via the debugging interfaces ?

I was negatively surprised myself. Unfortunately I cannot recall the
exact details (it was many moons ago), so I cannot reproduce the crash
anymore. In retrospect, I should have tried to run the same bytecode
'normally', to see if the problem was in the JVMTI interface, or in the
verifier. I do however suspect the JVMTI interface.

Hmm. I just tried to generate some bogus bytecode (replaced iadd with
fadd in an otherwise legal classfile), again using the JVMTI interface.
Now I get this message:

=============== DEBUG MESSAGE: illegal bytecode sequence - method not
verified ================

Error occurred during initialization of VM

(and a NullPointerException is thrown to boot!?)

I wonder how you are supposed to interpret "method not verified". Does
it mean "we did no real verification, but this is just obviously wrong"
or does it mean "we did verification, and it failed"? Shouldn't the VM
have thrown VerifyError?

In the case I was talking about earlier the VM did crash and burn, with
a segmentation fault IIRC.

 

[Chris Berg]

hi all,
I was asked by an interviewer as to how to crash a JVM.If any of
you know abt it let me know.

What about:

void func() {
func();
}

 

[Phillip Lord]

Chris> What about:

Chris> void func() {
Chris> func();
Chris> }


Doesn't crash the JVM, just runs it out of stack. To crash the JVM,
strictly there needs to be a bug. Look in the bug database. The
easiest way is to randomly edit some of the libraries with a hex
editor.

Phil

 

[Thomas Fritsch]

What about:

void func() {
func();
}

The JVM does not "crash" by this. It just throws a
java.lang.StackOverflowError and continues in the normal way,
which usually means 'aborting the current thread', because Error's
are rarely caught by the java application.
Try the following to convince yourself.

try {
func();
} catch(StackOverflowError e) {
System.out.println(e);
}
System.out.println("Processing continues...");

 

[Chris Uppal]

Hmm. I just tried to generate some bogus bytecode (replaced iadd with
fadd in an otherwise legal classfile), again using the JVMTI interface.
Now I get this message:

=============== DEBUG MESSAGE: illegal bytecode sequence - method not
verified ================

Error occurred during initialization of VM

(and a NullPointerException is thrown to boot!?)

I wonder how you are supposed to interpret "method not verified". Does
it mean "we did no real verification, but this is just obviously wrong"
or does it mean "we did verification, and it failed"? Shouldn't the VM
have thrown VerifyError?

I'm not sure, but I think that if VerifyError was thrown anywhere, it should
have been thrown to the code that caused the class to be loaded in the first
place, i.e. in the "debugee" rather than to the debugger (using the expression
"debugger" loosely).

I suspect that the verifier must have been run -- the difference between iadd
and fadd is fairly subtle, and I can't see how it could be detected until the
flow-of-control analysis that the verifier does after all the simpler,
structural, checks have completed.

The NullPointerException is interesting, though. Presumably there's still
something amiss in this area. Perhaps the verifier was invoked in your original
test, and did detect the "wrongness", but the bug that caused the crash was in
attempting to report the problem back -- a bug that has now been partially
fixed to cause a NullPointerException rather than a crash. But that is pure
guesswork...

-- chris

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

Chris Uppal wrote:

<snip stuff I wrote about weird behaviour when introducing illegal
bytecode dynamically in classfile>

I'm not sure, but I think that if VerifyError was thrown anywhere, it should
have been thrown to the code that caused the class to be loaded in the first
place, i.e. in the "debugee" rather than to the debugger (using the expression
"debugger" loosely).

Yes, this is the case. The JVMTI agent is written in C, and uses the
ClassFileLoadHook to rewrite classfiles (raw bytes) before the VM gets a
peek at them. Any Exceptions/Errors resulting from the rewrite should be
thrown in the java code that requested the class load.

(Perhaps we should introduce the term "bugger" for this kind of program)