RFR: 8314225: SIGSEGV in JavaThread::is_lock_owned [v9]

Kevin Walls kevinw at openjdk.org
Wed May 8 08:02:54 UTC 2024


On Wed, 8 May 2024 07:57:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Removal of JavaThread's MonitorChunks member.  This held lock information during deoptimization, but access to it is unnecessary for anything other than the deoptimization itself.
>> 
>> Access to it in is_lock_owned() was racy, and caused rare crashes.
>
> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8314225_is_lock_owned_no_monitor_chunks_check
>  - Add back the null checks in unpack_on_stack asserts
>  - Merge remote-tracking branch 'upstream/master' into 8314225_is_lock_owned_no_monitor_chunks_check
>  - fill_in assert update
>  - JavaThread comment update and synchronizer check before cast
>  - monitor->owner() == nullptr handling in fill_in
>  - Missing include
>  - Move is_lock_owned from Thread to JavaThread
>  - Remove JavaThread's is_lock_owned
>  - Feedback from Dean
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/e2822004...f4fe65d8

On the null checks in the unpack_on_stack asserts: I'm putting them back 8-)

In vframearrayelememnt::fill_in we itereate MonitorInfo*
That gives us the is_scalar_replaced information, which means the MonitorInfo has a null owner(),
and there is an incoming param realloc_failures which can tell us if something in the preceeding Deoptimization::realloc_objects call had an allocation failure, so something has a null oop (which could be a monitor owner I think we can say).

If the MonitorInfo is_scalar_replaced is true, then we do dest->set_obj(nullptr);

That should leave vframeArrayElement::unpack_on_stack seeing a null src->obj() where we iterate at line 315.

In unpack_on_stack there is no realloc_failures flag, and we aren't using a MonitorInfo so we don't have is_scalar_replaced to check.  It just has a BasicObjectLock that it pulls from the MonitorChunks array (and those aren't specifically initialized, other than what we set in fill_in).

unpack_on_stack has always called  src->lock()->move_to(src->obj(), top->lock());  without checking src->obj(), and this works, but there are decisions in move_to that make that work.  There should be a follow-up bug on making sure this is works intentionally, which I can log.

So should there be a src->obj() == nullptr check in the unpack_on_stack asserts?  Looks like yes.

assert(src->obj() == nullptr || ObjectSynchronizer::current_thread_holds_lock(thread, Handle(thread, src->obj())),  "should be held, before/after move_to");

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

PR Comment: https://git.openjdk.org/jdk/pull/18940#issuecomment-2099981747


More information about the hotspot-dev mailing list