I have a Java program (attached) that starts a headless LO process, connects to it using a named pipe and uses loadComponentFromURL to open an ODT file. Doing this with LO 24.8 works perfectly, but LO 25.2 crashes while reading the file. It happens with several ODT files that I've tried, all of which can be opened without problems from the GUI - the one I am testing with has been created in LO 25.2 and is completely empty. The stacktraces (attached) show that the crash happens in package/source/zipapi/ZipFile.cxx:1173 or package/source/zipapi/ByteGrabber.cxx:59 . The ODT file is 9312 bytes, so in ZipFile.cxx nLength = 9312, nSize = 534 and nEnd = 8778. This matches well with what I observe - just before the crash happens the seek method of the input stream is called with position = 8778, corresponding to ZipFile.cxx line 1169, and nBytesToRead is 534 in ByteGrabber.cxx line 59. Reproducible: Always Steps to Reproduce: 1. Run the attached Java class (with modifications to match file locations). Actual Results: LO 25.2 crashes with a SEGV Expected Results: LO loads the ODT file
Created attachment 2103502 [details] Stacktrace Stacktrace recorded by gdb from starting LO with --backtrace
Created attachment 2103503 [details] Stacktrace from coredump
Created attachment 2103504 [details] Java code demonstrating the problem To compile java_uno.jar, libreoffice.jar and unoloader.jar must be present. Paths in the code must be modified to where the LO installation and test document are. When running the LO installation folder must be given in the -Djava.library.path system property (-Djava.library.path=/usr/lib64/libreoffice/program e.g.)
Created attachment 2103505 [details] Test document
I have noticed that the memory handling at the crash site in ZipFile::findCentralDirectory() has been refactored from LO 24.8 to 25.2 to use a sal_Int8[] wrapped in a unique_ptr instead of a Sequence.
I don't know much about Java programming, anyway from a packaging POV starting with 25.2.0.1 Fedora LibreOffice has been built with unbundled JavaWebsocket. I've fired a test build in COPR re-enabling the bundled JavaWebsocket, maybe you can try to enable that COPR repo and reinstall LO from there (provided the build will finish ok). If using the bundled JavaWebsocket shows the same crash, I think it is better to report the bug upstream. Otherwise... I don't know what to do, the bundled and unbundled versions should be the same, so I would expect the same output from both.
I forgot to add the link to the test build: https://copr.fedorainfracloud.org/coprs/mattia/libreoffice-testing/build/9418951/
(In reply to Mattia Verga from comment #6) > I don't know much about Java programming, anyway from a packaging POV > starting with 25.2.0.1 Fedora LibreOffice has been built with unbundled > JavaWebsocket. I've fired a test build in COPR re-enabling the bundled > JavaWebsocket, maybe you can try to enable that COPR repo and reinstall LO > from there (provided the build will finish ok). > > If using the bundled JavaWebsocket shows the same crash, I think it is > better to report the bug upstream. Otherwise... I don't know what to do, the > bundled and unbundled versions should be the same, so I would expect the > same output from both. Thanks - I have in fact already reported the bug upstream ( https://bugs.documentfoundation.org/show_bug.cgi?id=167936 ). FWIW the root cause seems to be that the code that reads the ODT file assumes that the input stream will never be from a remote client, so it's independent of the (in my case Java based) client talking to LO.