-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8347779: sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java fails with Unable to deduce type of thread from address #23213
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
Conversation
|
👋 Welcome back mbaesken! A progress list of the required criteria for merging this PR into |
|
@MBaesken 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: 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 135 new commits pushed to the
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 |
Webrevs
|
| boolean res = launch(expectedMessage, Arrays.asList(toolArgs), true); | ||
| if (!res) { // try once more | ||
| launch(expectedMessage, Arrays.asList(toolArgs), false); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
launch() should take an allowRetry argument and only retry if true. This test is operated in two different modes. One is with an active target process and one is with a target process that should be stabilized and inactive. The latter is not allowed to retry since it should never fail. Also, it would help to add a comment as to why the retry is being done. See the comment in printStackTrace().
I think a better approach would be for launch() to just return if a retry should be done. testHeapDump() should check the result, and just immediately return true if launch() returns true.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
launch() should take an allowRetry argument and only retry if true.
Are you talking about public static void launch(String expectedMessage, String... toolArgs) ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but my suggestion on how to fix this might not be the best one. It's a bit hard to get the naming and usage of flags and logic right here. allowRetry, vs retry, vs doSleep. They all relate. Bottom line is that we should only ever attempt a retry if doSleep is false. Right now that flag is checked in printStackTraces(), and determines if true should be returned to allow a retry, but only if we aren't already doing a retry. Something similar needs to be done with launch() when it is deciding to return true or false after a failure. Right now it is only checking the allowRetry flag, but it should also check the doSleep flag.
I think in testHeapDump(), the calling of launch(String expectedMessage, String... toolArgs) should be done in a way similar to calling printStackTraces(). Pass in allowRetry and assign the result to the retry boolean. If retry is true, then return it right away (back to main() so it can retry). In launch(String expectedMessage, String... toolArgs), only call launch(String expectedMessage, List<String> toolArgs, boolean allowRetry) once, passing in allowRetry flag. In launch(String expectedMessage, List<String> toolArgs, boolean allowRetry), only return true to allow a retry if allowRetry is true and doSleep is false.
Anyway, it's kind of messy and there may be another way. The key issue with your current version is that it always allows for a retry, but it should only allow a retry if doSleep is false.
|
/label remove core-libs |
|
@AlanBateman |
|
I added more output as suggested and check doSleep in launch; are you fine with latest version ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's functionally correct but could use some comments.
| static boolean doSleep = true; // By default do a short sleep when app starts up | ||
|
|
||
| public static void launch(String expectedMessage, List<String> toolArgs) | ||
| public static boolean launch(String expectedMessage, List<String> toolArgs, boolean allowRetry) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should add a comment explaining the return value like we have for printStackTraces().
|
|
||
| launch(expectedMessage, Arrays.asList(toolArgs)); | ||
| boolean res = launch(expectedMessage, Arrays.asList(toolArgs), true); | ||
| if (!res && !doSleep) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should explain why we allow a retry here, and only for !doSleep, like we do in printStackTraces(). Note the doSleep reason is a bit different here. It is because the sleep allows the debuggee to stabilize, making it very unlikely that jmap will fail.
|
Hi Chris, I added comments . |
|
Thanks for the reviews ! /integrate |
|
Going to push as commit 04c24f1.
Your commit was automatically rebased without conflicts. |
We were running into this error :
sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
stderr: [java.lang.RuntimeException: Unable to deduce type of thread from address 0x0000ffff34144e30 (expected type JavaThread, CompilerThread, MonitorDeflationThread, AttachListenerThread, StringDedupThread, NotificationThread, ServiceThread or JvmtiAgentThread)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:196)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.getJavaThreadAt(Threads.java:178)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.dumpStackTraces(HeapHprofBinWriter.java:828)
at jdk.hotspot.agent/sun.jvm.hotspot.utilities.HeapHprofBinWriter.write(HeapHprofBinWriter.java:460)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.writeHeapHprofBin(JMap.java:216)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.run(JMap.java:103)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.startInternal(Tool.java:278)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.start(Tool.java:241)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.Tool.execute(Tool.java:134)
at jdk.hotspot.agent/sun.jvm.hotspot.tools.JMap.main(JMap.java:202)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.runJMAP(SALauncher.java:344)
at jdk.hotspot.agent/sun.jvm.hotspot.SALauncher.main(SALauncher.java:507)
Caused by: sun.jvm.hotspot.types.WrongTypeException: No suitable match for type of address 0x0000ffff34144e30
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.InstanceConstructor.newWrongTypeException(InstanceConstructor.java:62)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.VirtualConstructor.instantiateWrapperFor(VirtualConstructor.java:80)
at jdk.hotspot.agent/sun.jvm.hotspot.runtime.Threads.createJavaThreadWrapper(Threads.java:192)
... 11 more
In the discussion in the JBS bug it was found that a retry option in
launchshould be added.Progress
Issue
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/23213/head:pull/23213$ git checkout pull/23213Update a local copy of the PR:
$ git checkout pull/23213$ git pull https://git.openjdk.org/jdk.git pull/23213/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 23213View PR using the GUI difftool:
$ git pr show -t 23213Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/23213.diff
Using Webrev
Link to Webrev Comment