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

Kevin Walls kevinw at openjdk.org
Wed May 8 08:35:55 UTC 2024


On Fri, 3 May 2024 02:01:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   monitor->owner() == nullptr handling in fill_in
>
> src/hotspot/share/runtime/synchronizer.cpp line 1060:
> 
>> 1058:       // the ObjectMonitor.
>> 1059:     } else if (LockingMode == LM_LEGACY && mark.has_locker()
>> 1060:                && JavaThread::cast(current)->is_lock_owned((address)mark.locker())) {
> 
> This looks risky.  How about guarding it with a check for current->is_Java_thread()?

Yes!

> src/hotspot/share/runtime/vframeArray.cpp line 94:
> 
>> 92:         assert(!monitor->owner_is_scalar_replaced() || realloc_failures, "object should be reallocated already");
>> 93:         BasicObjectLock* dest = _monitors->at(index);
>> 94:         if (monitor->owner_is_scalar_replaced() || monitor->owner() == nullptr) {
> 
> The only way to get a null owner is if owner_is_scalar_replaced() is true:
> https://github.com/openjdk/jdk/blob/6bef0474c8b8773d0d20c0f25c36a2ce9cdbd7e8/src/hotspot/share/runtime/stackValue.hpp#L52
> and to get this far with it still null means `realloc_failures` is true.  We could avoid a null check later in unpack_on_stack if we skip adding to _monitors in this case.  So maybe use a GrowableArray inside MonitorChunk and add elements using append().
> Suggestion:
> 
>         if (monitor->owner_is_scalar_replaced()) {

Yes, no nullptr check needed there.
As discussed, moving to a GrowableArray complicates things quite a lot.  fill_in and unpack_on stack both make a similar iteration, but with slightly different information available.  Growing the array on demand and making both loops variable involves more changes in MonitorChunk and its accessors.  I think we're agreed to not be that disruptive for this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18940#discussion_r1593640314
PR Review Comment: https://git.openjdk.org/jdk/pull/18940#discussion_r1593639706


More information about the hotspot-dev mailing list