RFR (XS) 6471769: Error: assert(_cur_stack_depth == count_frames(), "cur_stack_depth out of sync")
Daniel D. Daugherty
daniel.daugherty at oracle.com
Mon Feb 3 14:38:27 PST 2014
On 2/3/14 12:12 PM, serguei.spitsyn at oracle.com wrote:
> On 2/3/14 4:16 AM, David Holmes wrote:
>> Hi Serguei,
>> On 1/02/2014 12:58 PM, serguei.spitsyn at oracle.com wrote:
>>> Please, review the fix for:
>>> Open webrev:
>>> There is a general issue in the suspend equivalent condition
>>> Two subsequent calls to the JvmtiEnv::is_thread_fully_suspended()
>>> return different results:
>>> - 1-st: true
>>> - 2-nd: false
>>> This more generic suspend equivalent issue is covered by another
>>> The bug to fix in this review is a specific manifestation of the
>>> in the JVMTI GetFrameCount() that has a big impact on the SQE
>>> It is on the Test Stabilization radar (as well as the 6280037).
>>> There are many tests intermittently failing because of this.
>>> The webrev for review is a one-liner work around the 6280037 for the
>>> The JVMTI GetFrameCount() spec tells:
>>> "If this function is called for a thread actively executing
>>> bytecodes (for example,
>>> not the current thread and not suspended), the information
>>> returned is transient."
>>> So, it is Ok to call the GetFrameCount() for non-suspended target
>>> To achieve safety, the frame count for non-suspended threads is
>>> calculated at a safepoint.
>>> It should be Ok and more safe to do the same for suspended
>>> threads as
>>> There is no big performance impact because it is already on a
>>> slow path.
>>> It is still important to avoid safepointing when the target
>>> thread is
>> This sounds completely reasonable - Reviewed.
>> I can't check at the moment whether VM_GetFrameCount properly checks
>> for a live target thread?
> David, thank you for the review!
> It looks like the check is missed.
> Please, give me some time to make sure what is needed here.
Check out the work done via this changeset:
Sergey did the push via:
JDK-8022836 JVM crashes in JVMTIENVBASE::GET_CURRENT_CONTENDED_MONITOR
but the real commentary about the bug is in this one:
JDK-7154963 crash in JvmtiEnvBase::get_current_contended_monitor()
I think above code is what you want...
>>> The bug 6280037 should go out of the Test Stabilization radar
>>> the svc-nightly label)
>>> as the most of the impacted tests are covered by the 6471769.
>>> In progress: nsk.jvmti, nsk.jdi, nsk.jdwp, impacted JTreg tests
More information about the hotspot-dev