RFR 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync")

[serguei.spitsyn at oracle.com]

On 2/25/14 2:57 PM, Daniel D. Daugherty wrote:
> On 2/25/14 1:43 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>>   https://bugs.openjdk.java.net/browse/JDK-6471769
>>
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1 
>>
>
> src/share/vm/runtime/vm_operations.hpp
>     No comments.
>
> src/share/vm/prims/jvmtiEnvBase.hpp
>     No comments.
>
> src/share/vm/prims/jvmtiEnv.cpp
>     No comments.
>
> src/share/vm/prims/jvmtiEnvThreadState.cpp
>     No comments.
>
> src/share/vm/prims/jvmtiThreadState.cpp
>     line 66:   _cur_stack_depth = UNKNOWN_STACK_DEPTH;
>         This looks like the key piece of this fix with respect to the
>         assert() in the bug report. I suspect that the first call to
>         JvmtiThreadState::cur_stack_depth() is racing with another
>         thread that happens to do something else that inits or sets
>         _cur_stack_depth to an acceptable value.

Another potential cause of the issue is that the cur_stack_depth() is 
called from the
update_for_pop_top_frame() which used to be called under suspend 
equivalent condition.
The update_for_pop_top_frame() has been changed to be called at a 
safepoint now.

>
>     line 251:     "must be current thread or at safepont");
>     line 284:     "must be current thread or at safepont");
>         typo: 'safepont' -> 'safepoint'
>
> Thumbs up! No need to re-review the typo fixes.

Sure. I'll fix it before pushing.

Thanks, Dan!
Serguei

>
> Dan
>
>
>>
>> Summary:
>>
>>   This is another Test Stabilization issue.
>>   The fix is very similar to other JVMTI stabilization fixes.
>>   It is to use safepoints for updating the PopFrame data instead of 
>> relying on the
>>   suspend equivalent condition mechanism 
>> (JvmtiEnv::is_thread_fully_suspended())
>>   which is not adequate from the reliability point of view.
>>
>> Testing:
>>   In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, JTreg com/sun/jdi
>>
>>
>> Thanks,
>> Serguei
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20140225/4e4c9753/attachment-0001.html