Open Echoloc8 opened 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.
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:
A resource failed to call end.
errors within the space of a few clock ticksOutput:
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:
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.