Webrev for 6972759

[Bill Pittore]

Thanks for the comment. I dug up a slightly dated (refers to SCCS ) 
coding convention document that recommends not to put bug IDs in the 
comments. I'll delete it.

thanks,
bill



On 1/12/2012 3:34 PM, yumin.qi at oracle.com wrote:
>  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
>>>>
>>>>
>>
>>