-
Notifications
You must be signed in to change notification settings - Fork 19
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
Fix NullPointerException on a parallel run #35
Conversation
👋 Welcome back jankratochvil! A progress list of the required criteria for merging this PR into |
@jankratochvil This change now passes all automated pre-integration checks. 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 no new commits pushed to the As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@dbessono) but any other Committer may sponsor as well. ➡️ To flag this PR as ready for integration with the above commit message, type |
Webrevs
|
could it be a dup of https://bugs.openjdk.org/browse/CODETOOLS-7903229 ? |
No, I have tried now that patch but it has no effect in this case. |
processFile(new File(TestResultTable.getRootRelativePath(this) + | ||
File.separator + filesToScan[i])); | ||
String path = TestResultTable.getRootRelativePath(this); | ||
if (path != "") | ||
path += File.separator; | ||
processFile(new File(path + filesToScan[i])); |
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.
Thanks for the suggested patch. I'd like suggest a bit more compact and direct, e.g.:
String path = TestResultTable.getRootRelativePath(this);
processFile(new File( "".equals(path) // Zero length string if the node is a root
? filesToScan[i] : (path + File.separator + filesToScan[i]) ));
processFile(new File( "".equals(path) // Zero length string if the node is a root | ||
? filesToScan[i] : (path + File.separator + filesToScan[i]) )); |
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.
Pretty ugly code, containing a complex expression inside the new File
, and even path string computation instead of using a better File
constructor.
I suggest something like:
processFile(path.isEmpty() // Zero length string if the node is a root
? new File(filesToScan[i])
: new File(path, filesToScan[i]));
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.
What if path
is null ?
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.
Also, it might be better not to pull in an additional constructor that was not used before, but rather maximally stick with the existing code and APi calls it does
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.
If null
is a possibility, check for it.
?? I don't understand the concern about referencing a different constructor that has been around since the beginning of Java time, and why it is better to do string arithmetic to construct a file path.
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.
Implicitly checking for null
here below.
If we could keep the existing approaches and API calls in the legacy code base, let's not pull anything new without necessity. I guess we don't have necessity to call an API that is new to this context.
processFile("".equals(path) // Zero length string if the node is a root
? new File(filesToScan[i])
: new File(path + File.separator + filesToScan[i]));
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.
If needed, refactoring like File
constructors call optimizations deserves to be better done with a separate commit.
The NullPointerException happens later in the code because the wrongly computed filename does not exist. (That could be an unrelated bug whether it should not be handled better, for example in the case someone deletes such file underneath.)
|
@jankratochvil thanks for the update. I guess even if some method now doesn't return null, we'd be better prepared if it starts in future due to some refactoring. Can see that the recent change failed jcheck
Once jcheck is OK, I guess we might be good to go to resolve the issues you are facing with a parallel run |
Error: Unexpected exception occurred! java.lang.NullPointerException java.lang.NullPointerException at com.sun.javatest.regtest.config.TestProperties$Cache.getEntryInternal(TestProperties.java:515) at com.sun.javatest.regtest.config.TestProperties$Cache.getEntryInternal(TestProperties.java:515) at com.sun.javatest.regtest.config.TestProperties$Cache.getEntry(TestProperties.java:502) at com.sun.javatest.regtest.config.TestProperties.getEntry(TestProperties.java:170) at com.sun.javatest.regtest.config.TestProperties.getTestNGRoot(TestProperties.java:123) at com.sun.javatest.regtest.config.RegressionTestFinder.scanFile(RegressionTestFinder.java:143) at com.sun.javatest.finder.TagTestFinder.scan(TagTestFinder.java:115) at com.sun.javatest.TestFinder.read(TestFinder.java:433) at com.sun.javatest.TRT_TreeNode.processFile(TRT_TreeNode.java:1259) at com.sun.javatest.TRT_TreeNode.scanIfNeeded(TRT_TreeNode.java:807) at com.sun.javatest.TRT_TreeNode.getTreeNode(TRT_TreeNode.java:616) at com.sun.javatest.TestResultTable.findNode(TestResultTable.java:400) at com.sun.javatest.TestResultTable.lookupNode(TestResultTable.java:533) at com.sun.javatest.TestResultTable.lookupInitURL(TestResultTable.java:571) at com.sun.javatest.TestResultTable.validatePath(TestResultTable.java:1000) at com.sun.javatest.regtest.config.TestManager.validatePath(TestManager.java:299) at com.sun.javatest.regtest.config.TestManager.getTests(TestManager.java:271) at com.sun.javatest.regtest.tool.Tool.createParameters(Tool.java:1659) at com.sun.javatest.regtest.tool.Tool.run(Tool.java:1293) at com.sun.javatest.regtest.tool.Tool.run(Tool.java:1082) at com.sun.javatest.regtest.tool.Tool.main(Tool.java:155) at com.sun.javatest.regtest.Main.main(Main.java:46) Some debug output showing the problem: scanIfNeeded getRootRelativePath= separator=/ filesToScan[i]=resultdir processFile file=/resultdir isAbsolute=true TestFinder.java read file=/resultdir isAbsolute=true scanFile caller file=/resultdir scanFile File=/resultdir TestProperties.java:dir=/ rootDir=/home/azul/azul/zulu11-git/test/hotspot/jtreg file2=/resultdir file2.getParentFile()=/ TestProperties.java:dir=null rootDir=/home/azul/azul/zulu11-git/test/hotspot/jtreg file2=/resultdir file2.getParentFile()=/ This happens with jtreg using -w:resultdir . getRootRelativePath() returns empty "" path. Other option would be to return "." but in such case it broke some other code. This problem does not happen during a single run. It happens only when jtreg is being run in parallel, in my case: seq 1 100000|xargs -n1 -P64 ./runtest #! /bin/bash dir=result-test$$ rm -rf $dir mkdir $dir set -o pipefail (JAVA_HOME=$HOME/azul/zulu11-git/build/linux-x86_64-normal-server-release/images/jdk/; $JAVA_HOME/bin/java -classpath $HOME/azul/jtreg/build/images/jtreg/lib/jtreg.jar:$HOME/azul/jtreg/build/images/jtreg/lib/javatest.jar:$HOME/azul/jtreg/build/images/jtreg/lib/asmtools.jar com.sun.javatest.regtest.Main -testjdk:$JAVA_HOME -othervm -verbose -ignore:quiet -retain:all -a -conc:1 -timeout:10 -vmoptions:-XX:+UnlockExperimentalVMOptions -w:$dir -noreport -dir:$JAVA_HOME/../../../../test/jdk/ -nativepath:$JAVA_HOME/../test/hotspot/jtreg/native ../hotspot/jtreg/vmTestbase/nsk/jdi/stress/serial/heapwalking001/TestDescription.java |& tee $dir/err) || exit 255 rm -rf $dir
@dbessono I am not sure - is this patch OK or should I check whether |
The current patch takes possible |
/integrate |
It won't generate NPE but it will produce |
@dbessono Only the author (@jankratochvil) is allowed to issue the |
/integrate |
@jankratochvil |
you are right, as a follow up I'd update the code to
|
/sponsor |
Going to push as commit 2b3e2b6. |
@dbessono @jankratochvil Pushed as commit 2b3e2b6. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
I see you have already done the |
yep, could you please check that the current state of the main JTH branch allows you to unblock the testing in the configuration you are using. |
I have verified: |
Thank you! Looks we could add a tag for b24 |
Some debug output showing the problem:
This happens with jtreg using
-w:resultdir
.getRootRelativePath()
returns empty""
path. Other option would be to return"."
but in such case it broke some other code.This problem does not happen during a single run. It happens only when jtreg is being run in parallel, in my case:
Unforunately I am not yet Author so I do not yet have a JBS account so I cannot file it to JBS (Java Bug System).
Progress
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jtharness pull/35/head:pull/35
$ git checkout pull/35
Update a local copy of the PR:
$ git checkout pull/35
$ git pull https://git.openjdk.org/jtharness pull/35/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 35
View PR using the GUI difftool:
$ git pr show -t 35
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jtharness/pull/35.diff