ngageoint / tiff-java

Tagged Image File Format Java Library
https://ngageoint.github.io/tiff-java
MIT License
72 stars 33 forks source link

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

Open Echoloc8 opened 1 year ago

Echoloc8 commented 1 year ago

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:

Expected Results:

Observed Results:

Output:

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.

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 commented 1 year ago

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.