Created attachment 204213 [details] Document that triggers the crash (PPTX) This looks remarkably similar to bug #168126 which after a couple of builds went away magically (and reappeared apparently). This is a regression between Version: 25.8.3.2 (X86_64) / LibreOffice Community Build ID: 580(Build:2) CPU threads: 12; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US and Version: 25.8.3.2 (X86_64) / LibreOffice Community Build ID: 580(Build:2) CPU threads: 12; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US
No crash observed. Gerald: if you indeed reproduce this in Safe Mode as well, please bibisect this with linux-64-26.2 repository. Arch Linux 64-bit Version: 25.8.3.2 (X86_64) / LibreOffice Community Build ID: 580(Build:2) CPU threads: 8; OS: Linux 6.17; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US 25.8.3-1 Calc: CL threaded
reproduce with Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 02b0772b31fe83f8dc5c6f196a82aea77a8db34f CPU threads: 4; OS: Linux 6.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded not reproduce(linux-64-26.2) Version: 26.2 .0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 177b3d2a88afb2dfd3e89025624d8bf62b36cda4 CPU threads: 4; OS: Linux 6.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded pngcheck image3.png CRC error in chunk iCCP (computed bc21deab, expected b892a448) For some reason, this problem cannot be reproduced in bibisect-repo. However, there seems to be a problem with image3.png.
(In reply to Saburo from comment #2) > pngcheck > image3.png CRC error in chunk iCCP (computed bc21deab, expected b892a448) Indeed, with a debug build I see this in the console: libpng warning: iCCP: CRC error libpng warning: izXt: CRC error libpng warning: iCCP: CRC error libpng warning: izXt: CRC error libpng error: Stream read: no data read from the stream.
Created attachment 204227 [details] PNG with CRC errors Output from `pngcheck -c -v`: chunk IHDR at offset 0x0000c, length 13 591 x 591 image, 32-bit RGB+alpha, non-interlaced chunk zTXt at offset 0x00025, length 12497, keyword: Raw profile type exif chunk iCCP at offset 0x03102, length 388 profile name = ICC PROFILE, compression method = 0 (deflate) compressed profile = 375 bytes CRC error in chunk iCCP (computed bc21deab, expected b892a448) https://github.com/pnggroup/pngcheck
not reproduced in Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 6cb040379ff0721c1e447baaa4a31aa7e3ae4ca6 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded with a debug build
warn:unotools.config:108391:108391:unotools/source/config/configitem.cxx:415: ignoring XHierarchicalNameAccess SnapGrid/Size com.sun.star.container.NoSuchElementException message: "SnapGrid/Size at /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/src_master/configmgr/source/access.cxx:448" context: configmgr::RootAccess libpng warning: iCCP: CRC error libpng warning: izXt: CRC error libpng warning: iCCP: CRC error libpng warning: izXt: CRC error libpng error: Stream read: no data read from the stream. Version: 26.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8c3fc56d37a557cf34a2a8a918eabd8811177514 CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Given that nobody but (In reply to Gerald Pfeifer from comment #0) > Created attachment 204213 [details] > Document that triggers the crash (PPTX) [...] and (In reply to Saburo from comment #2) > reproduce with > Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community > Build ID: 02b0772b31fe83f8dc5c6f196a82aea77a8db34f > CPU threads: 4; OS: Linux 6.14; UI render: default; VCL: kf5 (cairo+xcb) > Locale: ja-JP (ja_JP.UTF-8); UI: en-US > Calc: threaded [...] seems to be able to reproduce a crash, it could be helpful if one of you could provide a backtrace of that crash.
Not sure if it's helpful, but before the following commit in 7.2, the third, problematic image simply isn't shown, and there are no messages in the console, either: https://git.libreoffice.org/core/commit/e1d0846e060d2b3faedfe1a5877303037d8cf4d6 author Luboš Luňák <l.lunak@collabora.com> Fri Mar 05 19:55:43 2021 +0100 committer Luboš Luňák <l.lunak@collabora.com> Fri Mar 12 15:37:21 2021 +0100 "drop PNGReader and use only PngImageReader" Plus before this commit in 6.1, a missing image rectangle indicates there's supposed to be an image there: https://git.libreoffice.org/core/commit/edda1e5fc8113aa4744e32f97c96a3cc311485ca author Miklos Vajna <vmiklos@collabora.co.uk> Fri Apr 20 16:32:00 2018 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> Fri Apr 20 21:04:35 2018 +0200 "DOCX import: lazy-read images without external headers"
Created attachment 205462 [details] Minidump from crash This is a mini dump with the latest daily build: Version: 26.8.0.0.alpha0+ (X86_64) Build ID: 7829c6a12aea8e7b66acb1f86a04bc81a71d2d4c CPU threads: 14; OS: Linux 6.18; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US After showing: libpng warning: iCCP: CRC error libpng warning: izXt: CRC error libpng warning: iCCP: CRC error libpng warning: izXt: CRC error terminate called after throwing an instance of 'std::runtime_error' what(): Stream read: no data read from the stream.
Created attachment 205463 [details] gdbtrace.log from invoking LibreOffice with --backtrace After digging a bit more, when referring to a backtrace, is this what you had in mind? It's from invoking LibreOffice with --backtrace. (Sorry, this is a first for me. If there's something different, please advise and I'll look into it.)
(In reply to Gerald Pfeifer from comment #9) > terminate called after throwing an instance of 'std::runtime_error' > what(): Stream read: no data read from the stream. When looking at the code of the LO core repo at 7829c6a12aea8e7b66acb1f86a04bc81a71d2d4c, the above uncaught std::runtime_error is apparently thrown from within > if (!nBytesRead) > { > png_error(pPng, "Stream read: no data read from the stream."); > } in lclReadStream at vcl/source/filter/png/PngImageReader.cxx:47, which, due to the > png_set_error_fn(pPng, nullptr, lclError, nullptr); in reader at vcl/source/filter/png/PngImageReader.cxx:384, will (from within that png_error call) call vcl/source/filter/png/PngImageReader.cxx:60 > void lclError(png_structp /*pPng*/, png_const_charp error_msg) > { > throw std::runtime_error(error_msg); > } But that std::runtime_error should then be caught by the surrounding > try > { [...] > } > catch (const std::runtime_error& ex) > { > std::cerr << "libpng error: " << ex.what() << std::endl; > > pWriteAccessInstance.reset(); > return false; > } in reader at vcl/source/filter/png/PngImageReader.cxx:378. It is unclear to me why that std::runtime_error thrown from LO's libmergedlo.so, apparently passing through the system's /lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16.54.0, could then not be caught again in LO's libmergedlo.so. I would assume that it might have to do with how SUSE's LO and/or libpng are built.
(In reply to Stephan Bergmann from comment #11) > It is unclear to me why that std::runtime_error thrown from LO's > libmergedlo.so, apparently passing through the system's > /lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16.54.0, could then not be caught > again in LO's libmergedlo.so. I would assume that it might have to do with > how SUSE's LO and/or libpng are built. But the LO at least in attachment 205463 [details] is not a SUSE system-provided LO, but rather some (presumably TDF-built) /home/gp/lo268-26.8.0.0.alpha0-20260211/opt/libreofficedev26.8, so the last sentence above should rather read: "I would assume that it might have to do with how SUSE's libpng is built."
Ach, I had failed to notice that that "try to throw through libpng" pattern had only been introduced into the LO code relatively recently, with <https://git.libreoffice.org/core/+/6f92f2cb118cc97e57c57e02bef491ecf39b1f4a%5E%21> "ofz#435489660 Direct-leak from vcl::PngImageReader::read". And given that libpng is a C library, and throwing C++ exceptions through C code is generally known to not be reliable (e.g., for GCC you might need to have the C code built with -fexceptions), the attempt at using the "try to throw through libpng" pattern is probably not something that "was known to always work reliably in our code and now suddenly started to break for some user" but rather something that "was never known to work in general".
yeah, that only worked for me because Fedora builds everything with -fexceptions.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ee1b913c7108b1ecc40f284cfefb0c4c71d6a713 Resolves: tdf#169622 restore longjmp/setjmp for png failures It will be available in 26.8.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.
backport to 26.2 in gerrit
Confirming as fixed with the latest daily build Version: 26.8.0.0.alpha0+ (X86_64) Build ID: c32fcaa866ebdf11edab53e08bc62562e520ef0f CPU threads: 14; OS: Linux 6.18; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Thank you!
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-26-2": https://git.libreoffice.org/core/commit/e3b1bf131bbbf95293a616ea23bc9a54bd37f43c Resolves: tdf#169622 restore longjmp/setjmp for png failures It will be available in 26.2.2. 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.
Thank you for also pushing this to 26.2! Just one question: Wouldn't it make sense to add a testcase? What won't trigger on every system, depending on how libpng has been built, still would be better than no test at all? I failed to mark this VERIFIED with comment #17; doing this now.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-26-2-1": https://git.libreoffice.org/core/commit/d0b8af2b5667d2929c190cfa26df52f3ba4b1616 Resolves: tdf#169622 restore longjmp/setjmp for png failures It will be available in 26.2.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 Gerald Pfeifer from comment #19) > Thank you for also pushing this to 26.2! Just one question: Wouldn't > it make sense to add a testcase? What won't trigger on every system, > depending on how libpng has been built, still would be better than no > test at all? > > I failed to mark this VERIFIED with comment #17; doing this now. Hi Gerald, I tried to write a test in https://gerrit.libreoffice.org/c/core/+/200253. Since it doesn't fail for me, I tried in CI building it on top of the commit before the fix, but it didn't fail either, so I don't know how to test it.
It would have to be a build that uses the system png, not the internal one, and it then would only manifest on distros that don't build everything with -fexceptions so not Fedora/RHEL.
Is there a way I could test the testcase as a mere mortal (without a full LibreOffice build environment)? It should fail on my system.
(In reply to Gerald Pfeifer from comment #23) > Is there a way I could test the testcase as a mere mortal (without a > full LibreOffice build environment)? It should fail on my system. No, you have to become immortal and set up a build :) https://wiki.documentfoundation.org/Development/BuildingOnLinux After your have a full build, click the kebab menu button in the top right of https://gerrit.libreoffice.org/c/core/+/200253 and select Download patch and copy the cherry pick command. Then execute Xisco's test with: CPPUNIT_TEST_NAME="testTdf168126" make CppunitTest_vcl_png_test If you want to keep using the build environment, you can drop Xisco's patch with: git reset --hard HEAD~1