Repeated "System: A resource failed to call end." errors around the moment of writing the a tiff file

[Echoloc8]

We've been using this library since 2.0.0, and it's gotten us out of a few tiff-related scrapes with other libraries and frameworks! Hoping I can get this one annoyance fixed.

Version Information:

• TIFF Java Version: 3.0.0
• TIFF Java Source: Central Repository
• IDE Name & Version: Android Studio 2021.3.1 Patch 1
• Maven Version: (Studio's Gradle)
• Java Version: 11
• Platform & OS: running on Android OS 8-13, building on MacOS Monterey 12.6.1
• Other Relevant Libraries: OpenCV, maybe? We use no other tiff-related libs in this app.

Expected Results:

• Tiff file is created, added to and saves with no errors in the log

Observed Results:

• Tiff file is created, added to and saves properly, but there are hundreds of lines of A resource failed to call end. errors within the space of a few clock ticks
• How often does this occur? Every time the tiff file is added to or saved. Without adding or using the library our codebase doesn't make this error occur.

Output:

• Any logs, errors, or output messages?

Other than the A resource failed to call end. errors, no extraneous logging seems to occur, even with all filtering of strings and processes off.

An example:

2022-12-15 17:55:15.626 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.626 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.626 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.626 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 
2022-12-15 17:55:15.627 18569-18610/com.tms.android.driversidekick W/System: A resource failed to call end. 

Steps to Reproduce:

It's not difficult to reproduce. The code follows the idiom for writing to a file in the README.md file pretty closely.

• We create a TiffImage object

• Then we create a few FileDirectory objects, set tagging and formatting properties, add a Rasters object to each representing a page's bitmap, and add each directory to the TiffImage with a call like tiffImageObject.add(fileDirectory)

• Finally we save the tiff with a call to TiffWriter.writeTiff(file, tiffImageObject)

If needed I can put together a small example, but this style of code has produced this errors-in-the-log behavior over a few versions of this library, in two app codebases (one Java 11, one Kotlin), and of Android OS, Mac OS and Studio. I'm just reporting it now so as to try to be as clean as possible in this latest app's codebase.

Is there something non-obvious we should be closing, or perhaps some sort of threading or other resource-isolation practice we should be aware of? We're not changing screens or scopes in any way I would expect to subtly abandon or orphan objects.

[bosborn]

I can't seem to reproduce the log using the README code in an Android test or through our Android tiff usage.

Did you try a strict mode policy yet to identify it? Something like...

StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
        .detectLeakedClosableObjects()
        .penaltyLog()
        .penaltyDeath()
        .build());

If you have a standalone small example or test known to cause it, that could help.