Description: On pc Debian x86-64 with master sources updated yesterday, I got a png corrupted after having removed a slide and save. Steps to Reproduce: 1. Retrieve http://www.spaceeman.be/ftl/ftl-bases.odg (11MB) 2. copy with a renaming of odg in zip. Unzip the zip file and see the size of 100000000000002800000031FB2A5F08.png in Pictures, you'll get 380 here's the end of file with hexdump -C 00000160 ff ff 00 fc ff ff ff ff e3 9b ac 48 22 e2 d2 b0 |...........H"...| 00000170 00 00 00 00 49 45 4e 44 ae 42 60 82 |....IEND.B`.| 2. Open the odg file 3. Remove the last slide (24th) 4. Save 5. Copy/rename the saved file to a zip file. 6. unzip the zip file and see the size of 100000000000002800000031FB2A5F08.png in Pictures, you'll get 368 and here's the end this time: 00000160 ff ff 00 fc ff ff ff ff e3 9b ac 48 22 e2 d2 b0 |...........H"...| 00000170 For those who read French, see http://linuxfr.org/users/space_e_man/journaux/libreoffice-alteration-d-images-integrees Actual Results: See steps to reproduce because the actual results must be considered at different steps Expected Results: No corruption of the file. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
Caolán: thought you might be interested in this one since the pb seems in vcl/png Debugging in vcl/source/gdi/pngwrite.cxx, I compared the number of times that IHDR and IEND were called, it's the same. It seems more a kind of truncation to 16 bytes. 368/16 = 23
Interestingly, I tried to create a small file to reproduce this by using the image of size 380. The pb is that after having opened the file, added a slide and put something and saved, no change in the image size, still at 380. I wonder what triggers this truncation.
Confirmed with LO 6.0.0.3 & 4.4.0.3 / Windows 7. No repro with 4.3.0.4. => regression
When opening file, I noticed this kind of log: warn:vcl:24383:24383:svtools/source/graphic/grfmgr.cxx:1052: Deprecated URL 'vnd.sun.star.GraphicObject:1000000000000020000000204B249CA79A42C6D7' was used to create a GraphicObject warn:vcl:24383:24383:svtools/source/graphic/grfmgr.cxx:1052: Deprecated URL 'vnd.sun.star.GraphicObject:1000000000000020000000204B249CA79A42C6D7' was used to create a GraphicObject When saving, I noticed this kind: warn:legacy.tools:24383:24383:svtools/source/graphic/grfmgr.cxx:223: GraphicObject::ImplAutoSwapIn: could not get stream to swap in graphic! (=>KA) warn:svx:24383:24383:svx/source/svdraw/svdmodel.cxx:844: exception: 'N3com3sun4star3uno9ExceptionE msg: Element does not exist and cannot be created: "1000020100000300000003255D049303D4ACDF5C.png"' for 51 PNG files (there are 62 png) The one with size 368 instead of 380 isn't in the list.
I added some gdb traces in PNGWriterImpl::Write to control size of PNG written. I got only 6 files: Write nCheckSize=47008 Write nCheckSize=2412 Write nCheckSize=10064 Write nCheckSize=10190 Write nCheckSize=37955 Write nCheckSize=37955 Except if I did it wrong, none corresponds to the corrupted file :-(
I read the linuxfr journal too. I tried to reproduce that bug too. There are two different bugs here. · the PNG corruption · the way the PNG is displayed (all black) Let's focus in this bug on the PNG corruption. Another bug should be open for the display problem to check why lodraw was more resilient on bad files and allowed to display correctly a corrupted file. Now for the PNG corruption, that bug is very old. To be precise, I'm able to reproduce the corruption in LibreOffice 4.2.8.2 on Ubuntu 14.04, so it may be even older. That means that the impact will need to be checked as there may be a good amount of documents created with LibreOffice version that corrupted the files. As Julien stated, the problem is that the PNG is truncated from 380 to 368 bytes when the document is saved. @Julien: please don't use the initial ODG document as it contains a lot of images which will only add noise to your investigation. To reproduce the bug just: 1. Download the attached bird.png file (380 bytes) 2. Create a new ODG document 3. Insert bird.png in the document (Insert → Image → From file) 4. Save the document 5. Open the document with a zip-handling program like file-roller Expected result: The PNG file in the Pictures directory should be 380 bytes long Actual result: The PNG file in the Pictures directory is truncated to 368 bytes
Created attachment 139634 [details] bird.png
(In reply to Julien Nabet from comment #2) > Interestingly, I tried to create a small file to reproduce this by using the > image of size 380. > The pb is that after having opened the file, added a slide and put something > and saved, no change in the image size, still at 380. > > I wonder what triggers this truncation. Sorry, didn't noticed that remark before my comment. That's weird that the save procedure doesn't trigger the bug for you while it does for me on LO 4.2.8.2...
Some information about that image: $ hachoir-metadata ~/bird.png Metadata: - Image width: 40 pixels - Image height: 49 pixels - Number of colors: 2 - Bits/pixel: 1 - Pixel format: Color index - Compression rate: 0.8x - Compression: deflate - MIME type: image/png - Endianness: Big endian
Bibisecting lead to the following commit, but the previous commit also exhibits the bug when checking it directly, while the result was good during bibisecting. The results are not stable. I'll leave it for reference, though. https://cgit.freedesktop.org/libreoffice/core/log/?id=6e0e616f13c2bb2ce8493ac8442773c9bd78f5a0 Additionally, a bit before that there's a range where that specific image, and at least the next smallest one aren't exported at all.
(In reply to Luis Menina from comment #6) > ... > @Julien: please don't use the initial ODG document as it contains a lot of > images which will only add noise to your investigation. To reproduce the bug > just: > > 1. Download the attached bird.png file (380 bytes) > 2. ... I gave it a try, I don't reproduce this badfully. Indeed, I'd prefer too having a small file.
(In reply to Aron Budea from comment #10) > .. > I'll leave it for reference, though. > https://cgit.freedesktop.org/libreoffice/core/log/ > ?id=6e0e616f13c2bb2ce8493ac8442773c9bd78f5a0 > ... Looking at this commit, I don't know how it could have some impact on this but perhaps I'm wrong.
(In reply to Julien Nabet from comment #11) > I gave it a try, I don't reproduce this badfully. Indeed, I'd prefer too > having a small file. I had a doubt and tried again. I had triggered it at the first time, but now I'm unable to reproduce. I'll try to work on a better reproduction procedure. About the commit pointed, I also think it look unrelated.
(In reply to Julien Nabet from comment #12) > Looking at this commit, I don't know how it could have some impact on this > but perhaps I'm wrong. Yes, I wrote that the bibisect result was inconclusive as the repro was unstable: if I checked out this commit, then the previous, then the bug was reproducible at the previous commit as well (unlike during bibisecting), which makes it impossible for this commit to be the actual first bad one. That's why I commented the log instead of a reference to the individual commit.
In case it would be useful: in the original odg file, you can disassociate the group that has that image, then select the bird image and right click on it. Chose "save the image as" and you'll hit the bug: the saved image will be corrupted. I don't know however if it's already corrupted in-memory (at loading time) or at the moment it's written.
On pc Debian x86-64 with master sources updated today, this time 2 images are lost. Indeed, in the original file, there are 64 pngs, in the saved files 62 pngs. (Pictures/100000000000002800000031FB2A5F08.png is one of them).
Dear Julien Nabet, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
On pc Debian x86-64 with master sources updated today, I've got the same as what I noticed in my previous comment: "2 images are lost. Indeed, in the original file, there are 64 pngs, in the saved files 62 pngs." Another strange thing, here's part of list of original png files in the odg: 100000000000002800000031FB2A5F08.png 10000000000000640000006425A1490C.png 100000000000006400000064569B1D07.png 100000000000006400000064D6A5A521.png 100000000000010000000100E2562A3D.png and in the other file: 100000000000002800000031A5CC7D4A471BCF81.png 1000000000000064000000642DEA2EDCCFFBE966.png 1000000000000064000000649C6ED1F5B323061F.png 100000000000006400000064F711DB5D65BE962A.png 100000000000010000000100E98CDCAA9C42F685.png Is it expected or could there be some link?
(In reply to Luis Menina from comment #6) > > @Julien: please don't use the initial ODG document as it contains a lot of > images which will only add noise to your investigation. To reproduce the bug > just: > > 1. Download the attached bird.png file (380 bytes) > 2. Create a new ODG document > 3. Insert bird.png in the document (Insert → Image → From file) > 4. Save the document > 5. Open the document with a zip-handling program like file-roller > > Expected result: > The PNG file in the Pictures directory should be 380 bytes long > > Actual result: > The PNG file in the Pictures directory is truncated to 368 bytes I gave a try with master sources updated today, I don't reproduce this specific bug. However, I got a crash when following my initial comment, more tests needed here.