Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8281615: Deadlock caused by jdwp agent #7461

Closed
wants to merge 6 commits into from
Closed
Changes from 5 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 26 additions & 13 deletions src/jdk.jdwp.agent/share/native/libjdwp/classTrack.c
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
/*
* Copyright (c) 2001, 2005, Oracle and/or its affiliates. All rights reserved.
* Copyright (c) 2001, 2022, Oracle and/or its affiliates. All rights reserved.
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
*
* This code is free software; you can redistribute it and/or modify it
Expand Down Expand Up @@ -81,14 +81,22 @@ cbTrackingObjectFree(jvmtiEnv* jvmti_env, jlong tag)
struct bag *
classTrack_processUnloads(JNIEnv *env)
{
debugMonitorEnter(classTrackLock);
if (deletedSignatures == NULL) {
// Class tracking not initialized, nobody's interested.
debugMonitorExit(classTrackLock);
return NULL;
return NULL;
}

/* Allocate new bag outside classTrackLock lock to avoid deadlock.
*
* Note: jvmtiAllocate/jvmtiDeallocate() may be blocked by ongoing safepoints.
* It is dangerous to call them (via bagCreateBag/bagDestroyBag())while holding monitor(s),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: need space after ))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. Thanks, @dholmes-ora

* because jvmti may post events, e.g. JVMTI_EVENT_OBJECT_FREE at safepoints and event processing
* code may acquire the same monitor(s), e.g. classTrackLock in cbTrackingObjectFree(),
* which can lead to deadlock.
*/
struct bag* new_bag = bagCreateBag(sizeof(char*), 10);
debugMonitorEnter(classTrackLock);
struct bag* deleted = deletedSignatures;
deletedSignatures = bagCreateBag(sizeof(char*), 10);
deletedSignatures = new_bag;
debugMonitorExit(classTrackLock);
return deleted;
}
Expand Down Expand Up @@ -194,8 +202,11 @@ classTrack_initialize(JNIEnv *env)
void
classTrack_activate(JNIEnv *env)
{
// Allocate bag outside classTrackLock lock to avoid deadlock.
// See comments in classTrack_processUnloads() for details.
struct bag* new_bag = bagCreateBag(sizeof(char*), 1000);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think there can be any race during activation but this change is harmless.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not sure classTrack_activate() has the problem, but it is called outside of initialization, inside debug loop ... so I assume that event callback might happen.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. This code is called when the debug agent receives a CLASS_UNLOAD EventRequest (which the debug agent handles by requesting JVMTI GC_FINISH events). So there is nothing that prevents classTrack_processUnloads() from being called at the same time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case the classTrack_processUnloads is racing with the classTrack_activate call. I would not expect it to be possible to generate an event in relation to this before things have been "activated". But moving on ...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay I see from later comments that in fact no such race exists, but we have to synchronize with cbTrackingObjectFree

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bah! But then a comment after that says it does exist again.

There seem to be issues understanding exactly what the concurrent call sequences can be with this code.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you might be confusing classTrack_activate() with classTrack_reset(). I believe the former has a race but the latter does not.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...and even with the race, I still I think it is safe for a new bagSize(deletedSignatures) == 0 check to be added outside the lock. The only thing classTrack_activate() can do to deletedSignatures is set it when it is null. There is no risk of deletedSignatures being deleted and reallocated by another thread once you are in classTrack_processUnloads(). This is because it is called while holding the handlerLock, and as I explained elsewhere, by the time classTrack_reset() is called, it's no longer possible to be in classTrack_processUnloads().

debugMonitorEnter(classTrackLock);
deletedSignatures = bagCreateBag(sizeof(char*), 1000);
deletedSignatures = new_bag;
debugMonitorExit(classTrackLock);
}

Expand All @@ -214,12 +225,14 @@ void
classTrack_reset(void)
{
debugMonitorEnter(classTrackLock);
struct bag* to_delete = deletedSignatures;
deletedSignatures = NULL;
debugMonitorExit(classTrackLock);

if (deletedSignatures != NULL) {
bagEnumerateOver(deletedSignatures, cleanDeleted, NULL);
bagDestroyBag(deletedSignatures);
deletedSignatures = NULL;
// Deallocate bag outside classTrackLock to avoid deadlock.
// See comments in classTrack_processUnloads() for details.
if (to_delete != NULL) {
bagEnumerateOver(to_delete, cleanDeleted, NULL);
bagDestroyBag(to_delete);
}

debugMonitorExit(classTrackLock);
}