On Mon, 11 May 2026 08:12:14 GMT, David Holmes <[email protected]> wrote:
>> Yes, this is clearing locks specifically for a revived process, I can >> rename. Will make the assert a guarantee as well. >> >>> And if a mutex was locked at the time of the crash how can you just call >>> unlock from the current thread when it was not the owner? >> >> Yes, that is a problem, can't unlock a mutex you don't hold, hence this new >> method to unconditionally raw_set_owner(nullptr). >> >> The revival of memory has already revived Mutex states, and that can >> occasionally be a problem, e.g. crashing with heap lock held, and reviving >> that state. If we crash with the heap lock held, it's more useful to try >> and inspect the heap, than to refuse to try. 8-) >> >> But this is core file analysis after all, so we do understand that a crash >> happened at some random time and there is a chance things are in an >> inconsistent state. (If things are so inconsistent that the jcmd operation >> fails, it is likely that a native debugger is the tool to be using, not >> jcmd.) > > I don't follow what you are saying. You are calling `_lock.unlock()` which > will call `pthread_mutex_unlock` on the actual OS mutex. You can't > legitimately call that unless you are the owner. And even if that call > doesn't immediately break anything, if you execute code that needs to lock > that mutex the actual lock attempt may just block because it was already > locked. Seems to me that what you really need here is a form of the old "lock > barging" for the VMThread that will turn lock/unlock into no-ops for the > revived VMThread. I've now realised this lock clearing isn't working: previously I was reproducing the held lock manually, and moved to using -XX:TestCrashInErrorHandler=14 updated to acquire Heap_lock -- but that was not actually acquiring the lock, oops. So I had mistakenly left in this version that doesn't actually unlock locks. The plan was a revival-specific method that clears monitors, doing whatever it needs for locks to get ignored. It makes sense that it should need a PlatformMonitor::clear_for_revive() that can e.g. re-initialize the pthread_mutex. Updating... (Yes I thought there was a "VM thread can get through locks" feature, that may have been there when I first starting thinking about this all.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31011#discussion_r3226301894
