Webrev for 6972759

yumin.qi at oracle.com yumin.qi at oracle.com
Thu Jan 12 12:34:08 PST 2012


  Looks OK. One comment, should we include the CR<id> in comment? I 
remember it should not be there.

--Yumin

On 1/12/2012 12:24 PM, Bill Pittore wrote:
> Hi David,
>   Thanks for forwarding this to the SA list. I did run the nsk/jvmti 
> tests from the UTE area on sqenfs-1.us.oracle.com. There were no new 
> failures with this change.
>
> bill
>
>
>
> On 1/12/2012 2:54 AM, David Holmes wrote:
>> Hi Bill,
>>
>> I believe this should have gone out to the Serviceability list 
>> (cc'ed) instead of, or perhaps as well as, the runtime list.
>>
>> The change looks okay to me in that is does what you described it 
>> would. With JVMTI the proof-of-the-pudding is always in the testing 
>> and I assume the various JVMTI test suites have been thoroughly 
>> exercised ?
>>
>> Thanks,
>> David
>>
>> On 11/01/2012 8:40 AM, Bill Pittore wrote:
>>> Webrev for fix for 6972759 is at
>>> http://cr.openjdk.java.net/~bpittore/6972759/webrev.00/
>>>
>>> This bug has to do with single stepping after hitting an exception
>>> breakpoint. The short story is that JVMTI maintains some thread state
>>> information that was not updated correctly if a frame was popped off 
>>> the
>>> stack. When you pop a frame the exception state should go back to
>>> _exception_detected=false. Otherwise when MethodExit event is sent at
>>> some time in the future the 'was_popped_by_exception' flag will be set
>>> and the agent receiving the event may not re-enable single stepping
>>> properly. This problem will also affect ForceEarlyReturn code. 
>>> Hacked up
>>> a couple of existing nsk/jvmti tests to issue the necessary sequence of
>>> JVMTI calls/events in order to test original bug and this fix.
>>>
>>> bill
>>>
>>>
>
>


More information about the serviceability-dev mailing list