8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10

[plummercj]

The test is failing because it is detecting an extra instance of TestClass1. The test (the debugger side) first tells the debuggee to create 10 instances of TestClass1. The debugger then uses JDI ClassType.newInstance() to create 100 more instances. It then resumes the debuggee and uses RefrenceType.instances() to find out how many instances of TestClass1 are reachable. Since the 100 created by ClassType.newInstance() should not have any references keeping them live, the answer should be 10, but sometimes it ends up being 11, so there is an extra instance.

I determined that this extra instance is always the last of the 100 that are created with ClassType.newInstance(). It uses the JDI/JDWP invoker interface. I found the following code in the debug agent invoker.c to be the problem:

    if (!detached) {
        outStream_initReply(&out, id);
        (void)outStream_writeValue(env, &out, tag, returnValue);
        (void)outStream_writeObjectTag(env, &out, exc);
        (void)outStream_writeObjectRef(env, &out, exc);
        outStream_sendReply(&out);
    }
…
    if (mustReleaseReturnValue && returnValue.l != NULL) {
        tossGlobalRef(env, &returnValue.l);
    }

The first block is responsible for sending the reply to the debugger for the JDI ClassType.newInstance() call. returnValue is a JNI global ref to the object that was just created, and tossGlobalRef() frees it after the reply packet has been sent. The problem is that once the reply packet has been received by the debugger (for the 100th TestClass1 allocation), it resumes the debuggee and issues the ReferenceType.instances() call. This might be handled by the debug agent before it ever gets to the tossGlobalRef() call. So there will still be a reference to the 100th TestClass1 object.

The fix is to call tossGlobalRef() after we are done with returnValue, but before sending out the packet. We are done with returnValue once the outStream_writeValue() call has been made. I decided to handle exc (the exception object) in the same manner. Although no tests were failing as a result of releasing it after sending the reply, I think you could write a test that triggered an exception and verified that the exception was not still considered live after doing the resume.

Regarding any concerns you might have for moving tossGlobalRef() code from outside the if (!detached) to inside, if you follow the logic of this function you'll see that mustReleaseReturnValue can only be set true if detached is false. You'll also see that exc can only be non-null if detached is false. Thus these two tossGlobalRef() calls were only ever made when detached was false, and that remains true after my changes.

Regarding any concerns you might have for making the tossGlobalRef() calls outside of the locks, the locking is a remnant from when the exception and returnValue fields were referenced directly out of the InvokeRequest struct, which could be accessed by other threads. That is no longer the case after changes were made for JDK-8181419, which copied the fields into local variables. This code actually has been subject to a pretty long bug tail. See the last couple of long comments by me in JDK-8176567 for details.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issue

• JDK-8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10

Reviewers

• Serguei Spitsyn (@sspitsyn - Reviewer) ⚠️ Review applies to ce7cf1f
• Alex Menkov (@alexmenkov - Reviewer) ⚠️ Review applies to ce7cf1f

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6943/head:pull/6943
$ git checkout pull/6943

Update a local copy of the PR:
$ git checkout pull/6943
$ git pull https://git.openjdk.java.net/jdk pull/6943/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6943

View PR using the GUI difftool:
$ git pr show -t 6943

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6943.diff

[bridgekeeper]

👋 Welcome back cjplummer! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@plummercj The following label will be automatically applied to this pull request:

• serviceability

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (edf41b15)
• 00: Full (ce7cf1fd)

[sspitsyn]

The fix looks good to me. Nice analysis!

Thanks,
Serguei

[openjdk]

@plummercj This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8176567: nsk/jdi/ReferenceType/instances/instances002: TestFailure: Unexpected size of referenceType.instances(nsk.share.jdi.TestInterfaceImplementer1): 11, expected: 10

Reviewed-by: sspitsyn, amenkov

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 205 new commits pushed to the master branch:

• bdfa15d: 8250801: Add clhsdb "threadcontext" command
• fd9fb9a: 8279194: Add Annotated Memory Viewer feature to SA's HSDB
• 848b16a: 8272746: ZipFile can't open big file (NegativeArraySizeException)
• b734dc8: 8280055: JFR: Improve ObjectContext implementation
• 7acc4c7: 8280058: JFR: StreamUtils::getJfrRepository(Process) should print stdout and stderr
• 88a8b23: 8280076: Unify IGV and IR printing
• 9e3f68d: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations
• 9eb50a5: 8280010: Remove double buffering of InputStream for Properties.load
• 64c0c0e: 8276563: Undefined Behaviour in class Assembler
• d175d33: 8280079: Serial: Remove empty Generation::prepare_for_verify
• ... and 195 more: https://git.openjdk.java.net/jdk/compare/eaefb1a1ed9edea440628e3a5c5483ebd52bfcb0...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[plummercj]

/integrate

[openjdk]

Going to push as commit 46fd683.
Since your change was applied there have been 206 commits pushed to the master branch:

• e314a4c: 8280124: Reduce branches decoding latin-1 chars from UTF-8 encoded bytes
• bdfa15d: 8250801: Add clhsdb "threadcontext" command
• fd9fb9a: 8279194: Add Annotated Memory Viewer feature to SA's HSDB
• 848b16a: 8272746: ZipFile can't open big file (NegativeArraySizeException)
• b734dc8: 8280055: JFR: Improve ObjectContext implementation
• 7acc4c7: 8280058: JFR: StreamUtils::getJfrRepository(Process) should print stdout and stderr
• 88a8b23: 8280076: Unify IGV and IR printing
• 9e3f68d: 8279290: symbol not found error, implicit lambdas and diamond constructor invocations
• 9eb50a5: 8280010: Remove double buffering of InputStream for Properties.load
• 64c0c0e: 8276563: Undefined Behaviour in class Assembler
• ... and 196 more: https://git.openjdk.java.net/jdk/compare/eaefb1a1ed9edea440628e3a5c5483ebd52bfcb0...master

Your commit was automatically rebased without conflicts.

[openjdk]

@plummercj Pushed as commit 46fd683.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.