Problems with Directory Handling for -d,--dir Flag in NullAway Annotator

[akbarkanso]

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:

1. Create the nonnull_elements.tsv file if it does not exist, or
2. Properly handle an empty directory without requiring pre-existing files

Stack trace

Stack trace for DirectoryNotEmptyException:

Exception in thread "main" java.lang.RuntimeException: java.nio.file.DirectoryNotEmptyException: nullawayResults/0
	at edu.ucr.cs.riple.core.module.ModuleConfiguration.<init>(ModuleConfiguration.java:74)
	at edu.ucr.cs.riple.core.Config.lambda$new$0(Config.java:418)
	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
	at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
	at edu.ucr.cs.riple.core.Config.<init>(Config.java:420)
	at edu.ucr.cs.riple.core.Main.main(Main.java:43)
Caused by: java.nio.file.DirectoryNotEmptyException: nullawayResults/0
	at java.base/sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:246)
	at java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:110)
	at java.base/java.nio.file.Files.deleteIfExists(Files.java:1191)
	at edu.ucr.cs.riple.core.module.ModuleConfiguration.<init>(ModuleConfiguration.java:68)

Stack trace for NoSuchFileException:

Exception in thread "main" java.lang.RuntimeException: Error happened while loading content of file: nullawayResults/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: nullawayResults/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)

OS:

• OS: macOS
• Version: Sonoma 14.5

Annotator Version

• Annotator Version: 1.3.14
• NullAway Version: 3.40.0

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.

[msridhar]

@akbarkanso thanks for your report. We're a bit busy with deadlines until August 2, but after that @nimakarimipour will take a look.

[akbarkanso]

Hi @nimakarimipour, did you get a chance to check the above problem?

[nimakarimipour]

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:

1. Ensure that the path specified in AnnotatorScanner:ConfigPath in the build configuration matches the corresponding value in paths.tsv.
2. 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.

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.

[akbarkanso]

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.

[akbarkanso]

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.

[msridhar]

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?

[nimakarimipour]

@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.

[akbarkanso]

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.

[msridhar]

@akbarkanso

2. 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.

[akbarkanso]

@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

[msridhar]

@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.