Request for review 7009923: JSR 292: VM crash in JavaThread::last_frame

Coleen Phillimore coleen.phillimore at oracle.com
Tue Apr 26 07:55:57 PDT 2011


On 4/26/2011 1:17 AM, David Holmes wrote:
> Hi Coleen,
>
> Coleen Phillimore said the following on 04/26/11 12:37:
>> Summary: Handle stack overflow before the first frame is called, by 
>> printing out the called method and not walking the stack.
>>
>> % java IndyTest2
>> Exception in thread "main" java.lang.StackOverflowError
>>         at IndyTest2.main(IndyTest2.jasm)
>>
>> Also ran stack overflow tests.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/7009923/
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7009923
>
> So basically we ran out of stack before executing any Java code and 
> that caused us to try and create a StackOverflowError, for which the 
> backtrace was junk (because there is no Java stack) and that caused a 
> crash.
>
Right.

> Given this seems an extreme corner case and that no Java code has 
> actually been executed I'd be more inclined to simply skip the filling 
> in of the stacktrace - it is after all empty. I'm guessing the method 
> you are using is the method that would be called, but it seems wrong 
> to me to put that in the stacktrace as it indicates the overflow 
> occurred within that method, which it didn't.
Well the overflow occurred calling that method and this information 
might help the person defining said method some reason why it happened.  
So I think it's worth it and easy to do and right there.
>
> I'm also wondering what happens in the case of a JNI attached thread 
> which is not executing any Java code. Will a stackoverflow in native 
> code cause the VM to try and throw a StackOverflowError? If so won't 
> it have the same issue with no meaningful backtrace ?

No, native code does not throw StackOverflowError.  It crashes.
>
>
> In exceptions.cpp what is the significance of the change from:
>
>  _throw_oop(THREAD, file, line, exception());
>
> to
>
>  _throw(THREAD, file, line, exception);
>
They're equivalent, except the first takes the Handle off of exception, 
and in _throw_oop puts another Handle around exception so it's somewhat 
of a waste to have two handles for the same oop.

Thanks for the code review.

Coleen

> Cheers,
> David
>



More information about the hotspot-runtime-dev mailing list