Open akbarkanso opened 3 months ago
@akbarkanso thanks for your report. We're a bit busy with deadlines until August 2, but after that @nimakarimipour will take a look.
Hi @nimakarimipour, did you get a chance to check the above problem?
Hi @akbarkanso,
Thank you for reporting this issue, and apologies for the delayed response. We were tied up with a deadline but are now available to assist. From your bug report, it seems that the AnnotatorScanner may not be configured correctly. The error message nonnull_elements.tsv not found
suggests this, as nonnull_elements.tsv
and several other files are generated by AnnotatorScanner
.
AnnotatorScanner
is a plugin for Error Prone, similar to NullAway
, and must be added to the build configuration before running Annotator. Once the plugin is properly added, Annotator will compile the module, and the required files should be generated by AnnotatorScanner
. If you've already added AnnotatorScanner
, I recommend the following steps:
AnnotatorScanner:ConfigPath
in the build configuration matches the corresponding value in paths.tsv
.-rboserr
or --redirect-build-output-stderr
to redirect compilation output. This will help identify any crashes in the Scanner or errors in the build configuration. That would be very helpful if could provide this for us. You should expect to see NullAway warnings in the build output.Regarding the directory not empty
exception, this is likely due to manually creating nonnull_elements.tsv
using the touch
command. We actually prefer that users always pass an empty directory to Annotator, as it generates intermediate and large files that are unnecessary after execution. This allows you to easily delete the entire directory afterward without searching for individual files.
We will update the README
to include more detailed instructions and a sample project for running Annotator. Please let me know if you have any additional information or need further assistance, and sorry for any inconvenience caused.
Hi @nimakarimipour , Thanks for the detailed reply. I double-checked my configuration and re-ran the process, but I’m still encountering the same exception:
Exception in thread "main" java.lang.RuntimeException: Error happened while loading content of file: outDirN/0/nonnull_elements.tsv
at edu.ucr.cs.riple.core.registries.Registry.lambda$new$0(Registry.java:93)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at edu.ucr.cs.riple.core.registries.Registry.<init>(Registry.java:88)
at edu.ucr.cs.riple.core.registries.index.NonnullStore.<init>(NonnullStore.java:42)
at edu.ucr.cs.riple.core.module.ModuleInfo.<init>(ModuleInfo.java:90)
at edu.ucr.cs.riple.core.module.ModuleInfo.<init>(ModuleInfo.java:73)
at edu.ucr.cs.riple.core.Context.<init>(Context.java:78)
at edu.ucr.cs.riple.core.Annotator.<init>(Annotator.java:63)
at edu.ucr.cs.riple.core.Main.main(Main.java:45)
Caused by: java.nio.file.NoSuchFileException: outDirN/0/nonnull_elements.tsv
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:218)
at java.base/java.nio.file.Files.newByteChannel(Files.java:380)
at java.base/java.nio.file.Files.newByteChannel(Files.java:432)
at java.base/java.nio.file.spi.FileSystemProvider.newInputStream(FileSystemProvider.java:422)
at java.base/java.nio.file.Files.newInputStream(Files.java:160)
at java.base/java.nio.file.Files.newBufferedReader(Files.java:2922)
at edu.ucr.cs.riple.core.registries.Registry.populateContent(Registry.java:114)
at edu.ucr.cs.riple.core.registries.Registry.lambda$new$0(Registry.java:91)
... 8 more
My current configuration is as follows: I am adding the following to my compilation args: -XepOpt:NullAway:FixSerializationConfigPath=/path/root/outDirN/nullaway_config.xml -XepOpt:AnnotatorScanner:ConfigPath=/path/root/outDirN/nullaway_scanner_config.xml
My paths.tsv file available in /path/root/ content:
/path/root/outDirN/nullaway_config.xml /path/root/outDirN/nullaway_scanner_config.xml
the command I am running at root:
java -jar /path/annotator-core-1.3.14.jar -cn NULLAWAY -d "outDirN" -i com.Initializer -cp paths.tsv -bc "cd module && gradle compileAllJava" -rboserr
The gradle configuration is passing, and at the end of gradle execution, I can see that the task is failing due to current NullAway violations. In the terminal, after the build result, I see the nonnull_elements.tsv exception mentioned above.
Additional information:
If I run the gradle compileAllJava
command directly instead of java -jar /path/annotator-core-1.3.14.jar
, I notice that the AnnotatorScanner fails to create the outDirN directory, resulting in the following exception:
NoSuchFileException: /path/root/outDirN/nullaway_scanner_config.xml
However, running java -jar /path/annotator-core-1.3.14.jar ...
does create the outDirN
directory along with the nullaway_scanner_config.xml
and nullaway_config.xml
files beside the 0
directory, but it fails to create the outDirN/0/nonnull_elements.tsv
file.
Thanks for the further info, @akbarkanso. @nimakarimipour maybe we should land #239 and cut a release, so that @akbarkanso can provide more detailed info on what is going on here?
@akbarkanso @msridhar Released a new version (1.3.15
) with #239 included. This should give more information regarding the problem. I will soon add more instructions here on what can be to resolve / find the issue on this thread.
Hi @nimakarimipour,
I tried with the latest release, and indeed it fails in the recent code you introduced. The failure occurs after checking for the existence of outDirN/0/nonnull_elements.tsv
, which is not being created as mentioned in my previous comments.
Error message:
AnnotatorScanner is not correctly configured for the module: target.
Please verify that the path specified for AnnotatorScanner on line 0 in the configuration file matches the path provided in file with -cp/--config-paths, and that it is identical to the path specified with -XepOpt:AnnotatorScanner:ConfigPath.
If the path is set correctly, rerun annotator with -rboserr/--redirect-build-output-stderr flag and check compilation output and ensure NullAway and AnnotatorScanner is executing properly.
I have a feeling that AnnotatorScanner is not configured correctly, but I haven't been able to figure out what I did wrong. I already shared my configuration in my pervious comment.
@akbarkanso
- Rerun Annotator using
-rboserr
or--redirect-build-output-stderr
to redirect compilation output. This will help identify any crashes in the Scanner or errors in the build configuration. That would be very helpful if could provide this for us. You should expect to see NullAway warnings in the build output.
Just want to check, did you run with this option enabled? I'm wondering if there is a build failure. If you could run with this output and see if you notice any build failures or crashes that would be great.
@msridhar, sorry for the late reply. Unfortunately, adding -rboserr
did not provide any useful information. I am already passing it in my command, as mentioned in my previous comment
@akbarkanso does your Gradle project have multiple modules or a single module? Sorry we haven't been able to track this down. If there is any way you can create an open-source skeleton project that exhibits the same crashing behavior, that would help us a lot.
Describe the bug
I encountered issues when using the required -d,--dir flag to specify the directory for output serialization in NullAway Annotator. The tool expects a nonnull_elements.tsv file in the directory, but handling this file results in various exceptions.
To Reproduce
Steps to reproduce the behavior:
Run the NullAway Annotator with the Directory:
java -jar /path/to/annotator-core-1.3.14.jar -d "nullawayResults" .....
Encounter NoSuchFileException:
java.nio.file.NoSuchFileException: nullawayResults/0/nonnull_elements.tsv
Create the missing File:
touch nullawayResults/0/nonnull_elements.tsv
Run the NullAway Annotator Again:
java -jar /path/to/annotator-core-1.3.14.jar -d "nullawayResults" .....
Encounter DirectoryNotEmptyException:
java.nio.file.DirectoryNotEmptyException: nullawayResults/0
Expected behavior
The tool should either:
Stack trace
Stack trace for DirectoryNotEmptyException:
Stack trace for NoSuchFileException:
OS:
Annotator Version
Additional context
My understanding is that the specified directory should be any directory I wish to use for storing outputs. This directory should be a new, empty directory to be used by the tool.