Created attachment 202308 [details] Java code demonstrating the problem This problem has also been reported as https://bugzilla.redhat.com/show_bug.cgi?id=2388224 . I'm not sure if sdk is the proper component to report against; please move to other components as needed. 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. 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.
Created attachment 202309 [details] Stacktrace from --backtrace
Created attachment 202310 [details] Stacktrace from coredump
Created attachment 202311 [details] Test doc
Does it happen with 25.8?
Ah yes, it also crashes on Windows. Noel: it seems that ByteGrabber::ByteGrabber expects any passed stream to be an instance of our internal class, not expecting its API use?
Steps: 1. Download attachment 202308 [details] (LOTest.java) and attachment 202311 [details] (blank.odt). 2. Edit LOTest.java: 2.1. Line 63: change the first element of cmdArray into a path to your LO. In my case, it became "C:\\lo\\build\\instdir\\program\\soffice.com"; 2.2. Line 66: you may need to remove "--backtrace", because it makes LO fail on Windows with unknown argument; 2.3. Line 82: change odtDoc to point to your blank.odt (for me, it became "C:\\Downloads\\blank.odt"). 3. Run the result. E.g., my command line was: > java --class-path "C:\lo\build\instdir\program\classes\libreoffice.jar" C:\Downloads\LOTest.java
No clue why I didn't think of testing 25.8 :-/ 25.8 seems to behave the exact same way as 25.2. I don't have debuginfo available, so the stacktrace is a bit... well, sparse, but I get the exact same XSeekableInputStream API calls as with 25.2. The seek to position 8778 (ZipFile.cxx line 1167) is the last I see before the crash.
Created attachment 202317 [details] Stacktrace from LibreOffice 25.8
fix is here: https://gerrit.libreoffice.org/c/core/+/189577
(In reply to Noel Grandin from comment #9) > fix is here: https://gerrit.libreoffice.org/c/core/+/189577 Couple of possibly stupid questions: From looking at the diff it seems that ByteGrabber::readBytes still has the same problem? The crash happens in ZipFile.cxx line 1171 which is if (nSize != aGrabber.readBytes(aBuffer.get(), nSize)) Since ByteGrabber::ReadUInt64 reads 8 bytes, shouldn't aSequence be initialized with 8 as parameter?
*** Bug 167948 has been marked as a duplicate of this bug. ***
(In reply to Mikkel Lauritsen from comment #10) > Since ByteGrabber::ReadUInt64 reads 8 bytes, shouldn't aSequence be > initialized with 8 as parameter? I don't think we need to initialize it, actually. The sequence default initializer is basically assigning some static. And ReadBytes would re-assign the sequence anyway if needed, so the memory allocation would only happen if needed.
(In reply to Mikkel Lauritsen from comment #10) > Couple of possibly stupid questions: There are no stupid questions :-) > > From looking at the diff it seems that ByteGrabber::readBytes still has the > same problem? The crash happens in ZipFile.cxx line 1171 which is > No. It is not obvious, but this method is not an UNO method, so it is not used for your use-case.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7e71af5af43da1f7a7cb0bc4d5319f277a67738a tdf#167936 crash when opening document from UNO pipe It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/4d209d61df2aa0bd6af1f9db0525138f04f1ed56 tdf#167936 crash when opening document from UNO pipe It will be available in 25.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/ac5ace88c8500988b9ed4727ff96b2547a0db2d0 tdf#167936 crash when opening document from UNO pipe It will be available in 25.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #15) > Noel Grandin committed a patch related to this issue. > It has been pushed to "libreoffice-25-2": > > https://git.libreoffice.org/core/commit/ > 4d209d61df2aa0bd6af1f9db0525138f04f1ed56 > > tdf#167936 crash when opening document from UNO pipe > > It will be available in 25.2.6. > > The patch should be included in the daily builds available at > https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More > information about daily builds can be found at: > https://wiki.documentfoundation.org/Testing_Daily_Builds > > Affected users are encouraged to test the fix and report feedback. The dev build server has a folder named 2025-08-15_06.43.56 - assuming that the date given is in UTC the timestamp is in UTC+2 (which happens to be my timezone), so the build has been made this morning and should include the commit from yesterday. I have tried this build, and it still crashes the same way as before. No debuginfo, but the stacktrace is still basically the same: Thread 7 "cppu_threadpool" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffceffd6c0 (LWP 39142)] 0x00007ffff465cf81 in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #0 0x00007ffff465cf81 in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #1 0x00007ffff465ea1a in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #2 0x00007ffff467c045 in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #3 0x00007ffff048e5f0 in ?? () from /home/ml/libreofficedev25.2/program/libuno_cppuhelpergcc3.so.3 #4 0x00007ffff048e6dd in ?? () from /home/ml/libreofficedev25.2/program/libuno_cppuhelpergcc3.so.3 #5 0x00007ffff0491a68 in ?? () from /home/ml/libreofficedev25.2/program/libuno_cppuhelpergcc3.so.3 #6 0x00007ffff3f75419 in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #7 0x00007ffff3fa1fd6 in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #8 0x00007ffff41f970d in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #9 0x00007ffff41fd0de in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #10 0x00007ffff41ff661 in ?? () from /home/ml/libreofficedev25.2/program/libmergedlo.so #11 0x00007ffff41ffa0f in framework::Desktop::loadComponentFromURL(rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /home/ml/libreofficedev25.2/program/libmergedlo.so A stacktrace generated from a coredump goes a bit further; #0 above is #6 here: Stack trace of thread 42525: #0 0x00007fb9d0a10735 abort (libc.so.6 + 0x1735) #1 0x00007fb9d1fb0115 n/a (libmergedlo.so + 0x13b0115) #2 0x00007fb9d340da80 n/a (libmergedlo.so + 0x280da80) #3 0x00007fb9d43b1367 n/a (libmergedlo.so + 0x37b1367) #4 0x00007fb9d69af942 n/a (libuno_sal.so.3 + 0x67942) #5 0x00007fb9d0a28bb0 __restore_rt (libc.so.6 + 0x19bb0) #6 0x00007fb9d305cf81 n/a (libmergedlo.so + 0x245cf81) #7 0x00007fb9d305ea1a n/a (libmergedlo.so + 0x245ea1a) #8 0x00007fb9d307c045 n/a (libmergedlo.so + 0x247c045) #9 0x00007fb9cef015f0 n/a (libuno_cppuhelpergcc3.so.3 + 0x625f0)
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/d0530c1627cab736cf4636b4983b7d2d1f6a8882 tdf#167936 crash when opening document from UNO pipe (2) It will be available in 25.2.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Seems I missed a couple of places where we need to handle the external UNO case. Should be in tomorrows 25.2 build
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1ee8eb866bc7a4ae23107e76af97ac2ab4120e49 tdf#167936 crash when opening document from UNO pipe (2) It will be available in 26.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Noel Grandin committed a patch related to this issue. It has been pushed to "libreoffice-25-8": https://git.libreoffice.org/core/commit/80bf0371d375859adc7b2dc175190f9d62a20411 tdf#167936 crash when opening document from UNO pipe (2) It will be available in 25.8.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Noel Grandin from comment #19) > Seems I missed a couple of places where we need to handle the external UNO > case. Should be in tomorrows 25.2 build Looks good so far - my test case runs, and the application from which the test case has been derived has regained its ability to process ODT files. Many thanks!