Download it now!
Bug 115471 - PNG corrupted after saving
Summary: PNG corrupted after saving
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
4.2.8.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
Depends on:
Blocks: Graphics-Export
  Show dependency treegraph
 
Reported: 2018-02-05 15:58 UTC by Julien Nabet
Modified: 2020-01-31 09:28 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
bird.png (380 bytes, image/png)
2018-02-06 14:25 UTC, Luis Menina
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2018-02-05 15:58:32 UTC
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
Comment 1 Julien Nabet 2018-02-05 16:02:56 UTC
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
Comment 2 Julien Nabet 2018-02-05 16:07:56 UTC
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.
Comment 3 Aron Budea 2018-02-06 02:01:35 UTC
Confirmed with LO 6.0.0.3 & 4.4.0.3 / Windows 7.
No repro with 4.3.0.4.
=> regression
Comment 4 Julien Nabet 2018-02-06 10:30:58 UTC
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.
Comment 5 Julien Nabet 2018-02-06 13:23:41 UTC
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 :-(
Comment 6 Luis Menina 2018-02-06 14:24:20 UTC
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
Comment 7 Luis Menina 2018-02-06 14:25:39 UTC
Created attachment 139634 [details]
bird.png
Comment 8 Luis Menina 2018-02-06 14:31:48 UTC
(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...
Comment 9 Luis Menina 2018-02-06 15:03:07 UTC
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
Comment 10 Aron Budea 2018-02-06 18:20:54 UTC
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.
Comment 11 Julien Nabet 2018-02-06 18:52:26 UTC
(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.
Comment 12 Julien Nabet 2018-02-06 18:55:23 UTC
(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.
Comment 13 Luis Menina 2018-02-07 11:47:06 UTC
(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.
Comment 14 Aron Budea 2018-02-07 12:04:14 UTC
(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.
Comment 15 Luis Menina 2018-02-07 17:55:03 UTC
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.
Comment 16 Julien Nabet 2019-03-06 20:21:51 UTC
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).