This just bit us on Tika: https://bz.apache.org/bugzilla/show_bug.cgi?id=67767
The fix is easy. I can patch it today. It would be great to get it into 5.2.5. I'm sorry that I didn't catch it during the earlier regression tests...my fault. On Sun, Oct 15, 2023 at 4:34 PM 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 > > > > >
