[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR: 8266593: vmTestbase/nsk/jvmti/PopFrame/popframe011 fails with "assert(java_thread == _state
From:       Serguei Spitsyn <sspitsyn () openjdk ! java ! net>
Date:       2021-11-22 9:26:03
Message-ID: DkvpYldUuWDdZyWhuf2_l4Uwn3XfSFUr6BbVdIgrf4E=.a91f64e3-221c-4a81-b8f6-284756e7336d () github ! com
[Download RAW message or body]

On Thu, 18 Nov 2021 09:34:13 GMT, Serguei Spitsyn <sspitsyn@openjdk.org> wrote:

> > The test fails when the target JavaThread has is_exiting() status. In such a case \
> > the JvmtiExport::cleanup_thread(this) has already made a clean up of its \
> > jvmtiThreadState, so the JavaThread address returned by _state->get_thread() is \
> > 0xbabababababababa. The fix is to add a check for is_exiting() status into \
> > handshake closure do_thread() early. There following handshake closures are fixed \
> >                 by this update:
> > - UpdateForPopTopFrameClosure
> > - SetForceEarlyReturn
> > - SetFramePopClosure
> 
> Serguei Spitsyn has updated the pull request incrementally with one additional \
> commit since the last revision: 
> get rid of the checks in jvmti handshakes: java_thread->threadObj() == NULL

Hi David,
Thank you for looking at this and your comments.
Exiting thread should not be in suspended state.
Also, I'm pretty sure that the THREAD_NOT_ALIVE error code should normally take \
priority. So, I prefer current fix over moving the assert.
But I kind of understand you concern. Thank you for sharing it!
Thanks,
Serguei

-------------

PR: https://git.openjdk.java.net/jdk/pull/6440


[prev in list] [next in list] [prev in thread] [next in thread]