Only a small fraction of the tests using try-with-resources. So it is just possible that there are some bad tests that don't close the resources explicitly.
On Sunday 15 October 2023 at 21:34:52 IST, Dominik Stadler <dominik.stad...@gmx.at> wrote: Hi, I use file-leak-detector when running tests locally, this shows any left-over file-handles when running tests via the IDE. See https://github.com/jenkinsci/lib-file-leak-detector If you clone the latest version and build the tool locally via Maven, you can add something like the following in the run-config in the IDE: -javaagent:/opt/file-leak-detector/target/file-leak-detector-1.17-SNAPSHOT-jar-with-dependencies.jar=http=0,strong,excludes=/opt/poi/file-leak-detector.exclude,dumpatshutdown Then you will get a dump of all leftover file-handles at the end. In this case, it only happens if we enter the special catch-block in ZipPackage#ZipPackage(File, PackageAccess). One of the broken files from fuzzing seems to trigger this, constructing the package succeeds then, however with a resulting unclosed file-handle. So it seems to be less wide-spread than I originally thought and may actually have been the case before as well, not sure any more now... Dominik. On Sun, Oct 15, 2023 at 9:34 PM PJ Fanning <fannin...@yahoo.com.invalid> wrote: > Thanks Dominik for the feedback. The probable breaking change was: > > https://svn.apache.org/viewvc/poi/trunk/poi-ooxml/src/main/java/org/apache/poi/openxml4j/opc/ZipPackage.java?r1=1909467&r2=1909466&pathrev=1909467 > > > There have been some more changes, eg using java.nio.files.File to create > InputStreams instead of using FileInputStream. > > For this reason, I would prefer to use a test based approach to ensuring > the 'close' is called. Ideally, I would like to leave behind a regression > test. > > The ZipPackage change (r1909467) only affects the use of InputStreams and > does not affect the use of File inputs. The ZipPackage code is very > different on whether you start by providing an InputStream as opposed to a > java.io.File. In the latter case, we use a ZipFile class instance to do > random access to the wrapped files. > > Could you provide me with some example of what needs debugging? For > instance, would something like this not work ok? > > File file = .... > try (XSSFWorkbook wb = new XSSFWorkbook(file)) { > ... use wb > } > > Is the sort of usage you are suggesting where we would fail to close an > InputStream? > > > > > > > > > On Sunday 15 October 2023 at 19:37:33 IST, Dominik Stadler < > dominik.stad...@gmx.at> wrote: > > > > > > Hi, > > FYI, the current fix for not closing streams also does not close any stream > opened via a "File" parameter, so we are introducing many unclosed > resources via this change at the moment. > > Can we solve this somehow differently? Maybe cleanly revert the change > which introduced it? > > Thanks... Dominik. > > > > On Mon, Oct 9, 2023 at 1:47 PM PJ Fanning <fannin...@apache.org> wrote: > > > HI everyone, > > > > I think the regression in issue 67579 [1] is serious to warrant a new POI > > release. With that in mind, could we ramp down on changes while we decide > > if we want to release soon. > > > > I can do this one again unless someone else wants to do it. > > > > Regards, > > PJ > > > > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=67579 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
