(I am filing this bug to report a similar (maybe the same issue) as Bug 52226. Bug 52226 was fixed some days ago, but I still reproduce it with 4.3.1.1 release, so that commit seems not fix the issue.) DESCRIPTION: Images in a document will be lost (showing "read error"), at the time auto-save is triggered. For me and for this case, it happens in ODT document. STEPS TO REPRODUCE: 1. Set auto-save interval to 1 minute. 2. Downloand and open this LibreOffice 4.2 User Guide ODT document here: https://wiki.documentfoundation.org/images/6/6d/GS4202-SettingUpLibreOffice.odt 3. Hit ENTER to make the document modified, then wait for the auto-save to come. 4. When auto-save is finished, scroll up and down to observe that many images are showing "read error", images are gone, leaving only a placeholder and the error msg. 5. Save the document and reopen, "read error" messages are gone, and the images as well as place holders are no longer there. The only workaround is to disable auto-save. I set this to "BLOCKER" because by default auto-save is set 15 minutes, so users will lost their images after 15 minutes for sure. I do not reproduce following the above steps in versoin 4.1.6.2, so it's a regression. Version: 4.3.1.1, Build ID: c4b15cd4d00dec6b266fa830b4ba73e31ae6ce73 Win7
Created attachment 105109 [details] images in this document are lost This is the document after auto-save, images in page 4,7,9,10...are lost.
Confirmed this behaviour in 4.2.6, 4.3.2 and master and not in 4.1.6 on Linux. It happens with some PNG files and not others, the first image lost is on page 4 (figure 1).
Created attachment 105112 [details] how it looks after the autosave happens
(In reply to comment #0) > (I am filing this bug to report a similar (maybe the same issue) as Bug > 52226. Bug 52226 was fixed some days ago, but I still reproduce it with > 4.3.1.1 release, so that commit seems not fix the issue.) probably the patch did not fixed the bug 100% and there's residual issues still pending. is this happening just with some PNG files (Jay said some are unaffected) or with others image extensions as well? (In reply to comment #3) > Confirmed this behaviour in 4.2.6, 4.3.2 and master and not in 4.1.6 on > Linux. It happens with some PNG files and not others, the first image lost > is on page 4 (figure 1). the fix for Bug 52226 is present in 4.2.7, 4.3.0 and 4.4.0 master. so 4.2.6 is still unpatched.
*** Bug 82964 has been marked as a duplicate of this bug. ***
I can reproduce this on LibreOffice 4.3.2 (the latest release), using the steps Kevin Suo pointed out. I have a few users reporting missing images, so will test whether turning off autosave fixes this as well. The document I have is missing placeholders, and any sign there has been a lot of images included.
*** Bug 74703 has been marked as a duplicate of this bug. ***
*** Bug 84928 has been marked as a duplicate of this bug. ***
Seems images are being lost in ODPs as well (bug 46447). Wonder if these two are related?
(In reply to Jay Philips from comment #9) > Seems images are being lost in ODPs as well (bug 46447). Wonder if these two > are related? Yes in the sense that image caching in general is a problematic part of the code. There is bug 47148 for that.
*** Bug 85025 has been marked as a duplicate of this bug. ***
*** Bug 85250 has been marked as a duplicate of this bug. ***
(In reply to tommy27 from comment #4) > .... > > is this happening just with some PNG files (Jay said some are unaffected) or > with others image extensions as well? SVG affected as well. see duplicate Bug 85250. edited summary notes.
bibisected: Issue introduced in range: http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=474f48492547ff28803ee44dcd3bccb48f533a3e..b421ce79e39867917ba53be7bf69c8a4e7f8a8ac
Plain bisect in the vicinity of the above range points to the following specific commit: commit 192abfb36b8a4859879fcb49326d59ed62083c8d Author: Oliver-Rainer Wittmann <orw@apache.org> Date: Mon May 19 11:37:11 2014 +0000 Resolves: #i114361# provide and accept changed URL... of embedded graphic file during save (ODF export) (cherry picked from commit a90c007908eb3f66e28a9ea525729065db652b6f) Conflicts: sw/inc/ndgrf.hxx sw/source/core/graphic/ndgrf.cxx sw/source/core/unocore/unoframe.cxx sw/source/filter/xml/xmltexte.cxx xmloff/source/draw/shapeexport2.cxx Change-Id: I9d4a02af2561467fe1a66f036b55d6dcf2429986
Possibly related. I have not filed a bug yet as still testing. I have had auto-save and backup copy turned off for years since first discovering the bug. Now in 4.1.6.2 if I right click an image>Compress graphic I will get a read error on graphics somewhere else in the document and loose the image. If I don't compress I don't loose images.
It seems that the commit that caused this regression was identified. (Or at least a commit is suspected as the offending one.) Thus setting keyword "bisected".
Is this reproducible in 4.3.3 or 4.2.7 or master. Because while the above commit did break graphic save, there was some follow up patches which were supposed to fix it again, e.g. 05e07167e422caf58d23ff883edda30acc3ba88d and I can't reproduce with 4.2.7 and master with an x86_64 dbgutil build
I can't reproduce this issue with master ( Version: 4.4.0.0.alpha1+ Build ID: b7d8a58ff2698ffc6e22943f64aa97c5ea253bd9 ) in Ubuntu 14.10 x86_64
Caolan: At least on 2014-10-20 it wasn't fixed in 4.3.x: https://bugs.freedesktop.org/show_bug.cgi?id=85250#c6 tommy27 can probably give more details, but that bug is easy to reproduce anyways.
Also reproducable on 4.3.3
*** Bug 81877 has been marked as a duplicate of this bug. ***
Reproducible here again. LO Version: 4.3.3.2 Build ID: 9bb7eadab57b6755b1265afa86e04bf45fbfc644. (Debian Wheezy 7 with official wheezy-backports on AMD A4-5300 APU with Radeon(tm) HD Graphics on MSI A78M-E35 motherboard).
Zolnai Tamás committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=286e2f5c6ec829bc0987b1be7016699f7ef03e5e Related fdo#82953: Forget package URL of image after it is loaded It will be available in 4.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi there, I pushed a commit, which can fix this issue. I'm not 100% sure because I can't reproduce this problem on master or on 4.3.4 branch, but can with 4.2.6. So as caolan said potentially it is already fixed by his follow up patches. This patch I pushed is a general solution for all problems caused by that odt imported images are handled on a different way (as directly inserted ones for example). A similar problem what I found is that sometimes the thumbnail in the exported odt shows read error at the place of the images, but after opening the file it , images are there. In case of this thumbnail problem I could verify that the commit worked, so hopefully it can improve the situation here too.
I can reproduce it on 4.3.4.. So I think I want your 4.3.4 ;-)
Pushed to -4-3: http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3&id=33ab79d7e324489194b086812c920af06870e032
*** Bug 86064 has been marked as a duplicate of this bug. ***
(In reply to Jan Jurkus from comment #26) > I can reproduce it on 4.3.4.. So I think I want your 4.3.4 ;-) Whiteboard shows "target:4.3.5", so could you give a try to daily build of 4.3 (see http://dev-builds.libreoffice.org/daily/libreoffice-4-3/) ?
> Whiteboard shows "target:4.3.5", so could you give a try to daily build of > 4.3 (see http://dev-builds.libreoffice.org/daily/libreoffice-4-3/) ? Tried it, didn't work. One image survived that didn't before, but others were still lost. In case it matters, the documents that I encountered this bug in were created with OpenOffice under Windows, I'm editing them with LibreOffice under Linux.
I downloaded the following prerelease versions from https://www.libreoffice.org/download/libreoffice-fresh/ LibreOffice_4.2.8.2_Win_x86.msi LibreOffice_4.3.5.1_Win_x86.msi LibreOfficeDev_4.4.0.0.beta2_Win_x86.msi 4.2.8.2 and 4.3.5.1, It works! I can't believe it! And _they_ said imitiation diamond wasn't good enough! 4.4.0.0.beta2, Uh oh! Cheap mail-order jewels! In other words, it seems to have been fixed on the 4.2 and 4.3 branches, but not on the 4.4!
(In reply to Jan Jurkus from comment #31) I can't reproduce this using the original instructions on 4.4.0beta1 or beta2 on OSX, or on master on Linux Could you possibly confirm that you are still using the original instructions and file, and that you've checked (from within LibreOffice) that it's definitely 4.4.0beta2 that's running? If the answer to both is yes, then perhaps someone (Jay Philips?) would be good enough to try to reproduce again on Windows with 4.4.0beta2
(In reply to Jan Jurkus from comment #31) > .... > > In other words, it seems to have been fixed on the 4.2 and 4.3 branches, but > not on the 4.4! try a most recent 4.4.x daily build from here http://dev-builds.libreoffice.org/daily/libreoffice-4-4/ and copy and paste information about the build from help/anout LibO dev here.
@Kevin Suo you are the original reporter of this bug. please retest with newer LibO releases and tell if this issue is really fixed.
(In reply to tommy27 from comment #34) Will do later,thanks.
(In reply to tommy27 from comment #33) > try a most recent 4.4.x daily build from here > http://dev-builds.libreoffice.org/daily/libreoffice-4-4/ > and copy and paste information about the build from help/anout LibO dev here. Did that, and the problem seems fixed. To make absolutely sure I was using that version I reinstalled the VM. Working version: Version: 4.4.0.0.beta2+ Build ID: 8cb37cc090f754c4dafe5731c827539f01743671 TinderBox: Win-x86@42, Branch:libreoffice-4-4, Time: 2014-12-09_04:54:46 Locale: en_US Als rechecked this version: Version: 4.4.0.0.beta2 Build ID: be92f32b8f21603a6b7a75dd645f7475bdee519d Locale: en_US And this seems to also work! So the report about 4.4 not working is probably due to something I did wrong. Sorry, mea culpa!
Tried today's nightlies, this time both branches (4.4 and 4.3, previously I only tested 4.3). Result: Works with both, the document supplied by Kevin and the one I had problems with: Version: 4.4.0.0.beta2+ Build ID: a87db12c78d073dbfea50c833c25360285787054 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-4, Time: 2014-12-10_01:03:50 Locale: de_DE Not working, neither with the provided one nor with my own document: Version: 4.3.6.0.0+ Build ID: dcc914ab55feb844d5d71e6568801fa1ffd47f6c TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-12-09_00:31:21
From what I read here, several users have tested 4.4b2 and found the problem to be fixed. Thus setting to Fixed and assigning Zolnai who provided the patch. Re-open if this still happens for you with LO 4.4b2 or newer.
Due to mixed feedback for 4.3.6+0 I tested this: OSX 10.10.1 LO Version: 4.3.6.0.0+ Build ID: 8283eeec48d8b0cd6a001eeb3c6a532d17a2656c TinderBox: MacOSX-x86@49-TDF, Branch:libreoffice-4-3, Time: 2014-12-11_01:20:06 http://cl.ly/image/3B1q3i122h2H Activated auto-save, waited, and all images did show fine. So ok to close this. Jan-Philipp could you retry with the latest 4.3.6 nightly and try again if this works for you. Maybe only persisting on Linux now? Or maybe also another issue is persisting but this one is closed?
(In reply to foss from comment #39) > Due to mixed feedback for 4.3.6+0 I tested this: > > OSX 10.10.1 LO Version: 4.3.6.0.0+ > Build ID: 8283eeec48d8b0cd6a001eeb3c6a532d17a2656c > TinderBox: MacOSX-x86@49-TDF, Branch:libreoffice-4-3, Time: > 2014-12-11_01:20:06 > > http://cl.ly/image/3B1q3i122h2H > > Activated auto-save, waited, and all images did show fine. So ok to close > this. > > Jan-Philipp could you retry with the latest 4.3.6 nightly and try again if > this works for you. Maybe only persisting on Linux now? Or maybe also > another issue is persisting but this one is closed? Okay, then this seems to be a platform-dependent problem. I tested Version: 4.3.6.0.0+ Build ID: 8283eeec48d8b0cd6a001eeb3c6a532d17a2656c (same as foss!) TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:libreoffice-4-3, Time: 2014-12-11_05:02:38 with the Getting Started document and still had the problem of 26 (out of 31) images disappearing. https://jplitza.de/tmp/lowriter_read_error.png
(In reply to Jan-Philipp Litza from comment #40) I can confirm that with Debian Linux Wheezy. So I reopen.
But no. This critical bug is fixed in 4.4 nightly but not in 4.3.6, that I have used, for now.
Installed 4.5.3 (Windows) and it still LOSES images (tested with file from bug description). Also tested with another files (our logos on templates...)and it loses images as described on bug submit. I hope this bug will be re-open as its NOT solved.
> Installed 4.5.3 (Windows) and it still LOSES images (tested with file from > bug description). 4.5.3, wow! ;-) I can confirm it is indeed not fixed with 4.3.5: Version: 4.3.5.2 Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 However, could it be that the fix was not included in this version?
Hi, I think there were more causes of this image loss bug. One should be fixed now, but it seems others not. I've done some cleanup in image handling on master / 4.4 which can solve the whole problem, but this whole clean up can't be backported to 4.3. I can't reproduce the image loss, so I can't find out which patch fixed it. If anybody has time to bibisect the commit which fix the problem on 4.4 branch, it would be helpful.
(In reply to Jan Jurkus from comment #44) > > Installed 4.5.3 (Windows) and it still LOSES images (tested with file from > > bug description). > > 4.5.3, wow! ;-) > I can confirm it is indeed not fixed with 4.3.5: > Version: 4.3.5.2 > Build ID: 3a87456aaa6a95c63eea1c1b3201acedf0751bd5 > > However, could it be that the fix was not included in this version? WOW indeed! my mistake - 4.3.5.2 indeed...thx for correction, i didnt notice till i saw the WOW
I suggest the users that were able to reproduce the bug with 4.3.5 to retest the same with 4.4.0 beta to see if the issue is effectively fixed in the 4.4.x branch or if it's still some residual issue even in that branch
Tested with 4.4.0.1 1ba9640ddd424f1f535c75bf2b86703770b8cf6f PT-PT (both on XP and Windows 7), with file in attachment and also with our templates with logos and it WORKED fine. So it seems this bug doesnt affect 4.4.x as it does on 4.3.x
so good news is that bug is gone in 4.4.x (4.4.0 will be released in february 2015) and bad news is that some issues persist in 4.3.5 if users want to see this fixed in next 4.3.x releases (4.3.6 due in feburary 2015) a 4.4.x bibisect to find the exact committ fixing the residual issue has to be performed in order to allow a 4.3.x backport if technically feasible (see comment 45) so I set status again to FIXED since this works in the 4.4.x branch.
I'm not completely sure if this is the same bug, but I'm seeing read errors after auto-save with our WMF logo in an old document. Like all of the other comments here, I still experience the error with LO 4.3.5.2, but could not reproduce it using LO 4.4.0 beta2. These tests were performed using 32bit Fedora 17. Since this is a pretty horrible bug, I would hope that this could be fixed in 4.3.x. Still, thanks for all of the hard work fixing this for 4.4.x!
I finally downloaded the 4.4 bibisect environment. It looks like the commit that fixed this issue just barely made it in that commit range. I would be quite happy if this fix could still be backported to 4.3.x. 03feacde7d0d974d28adae78a32a9e0a85e68208 is the first bad commit commit 03feacde7d0d974d28adae78a32a9e0a85e68208 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Fri Oct 17 19:56:34 2014 +0000 source-hash-d9b9f50242ece39f9ecbbb24128ae3eff4c3319e commit d9b9f50242ece39f9ecbbb24128ae3eff4c3319e Author: Markus Mohrhard <markus.mohrhard@collabora.co.uk> AuthorDate: Fri May 23 20:51:30 2014 +0200 Commit: Markus Mohrhard <markus.mohrhard@googlemail.com> CommitDate: Sat May 24 10:48:43 2014 +0200 avoid the creation of empty text Change-Id: If1be3f50ed4ceac40b513b341f411fc2d2533f7f :100644 100644 5f4f478cbec24fb1867a4df4e258de7ac502366e 3fe6715d358873988070fa1a52834f85d6aa0264 M ccache.log :100644 100644 a0ef9f957436f15c18f64d38ac115a97e64cb1be e5af6940636fe7a1ed8f31af18096b0dc23c2c8a M commitmsg :100644 100644 35b812d17ebfbc5ae40f80b9f71a536a02af3830 176ca9c888502dcdb39403d827fdf9120da706c0 M make.log :040000 040000 cc74f7751e1c5ee9ad35d72a512c52ce71b1bce3 2d735ae783b56d4752a99488f414399d4edaed18 M opt $ git bisect log # bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 # good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect start 'latest' 'oldest' # bad: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81 git bisect bad 5d0dfb8e62ae61a240f8313c594d4560e7c8e048 # bad: [c0ef5c9ad28738878bb28206d62a57aa367cad92] source-hash-d47678c990681d0cfc7f2c843bb9aedaeb08511a git bisect bad c0ef5c9ad28738878bb28206d62a57aa367cad92 # bad: [652c8d1675dc8b174de907d4204dbc2ec98fe325] source-hash-0aa3dee5e88a1494a7a6a8401e084cbdb4324727 git bisect bad 652c8d1675dc8b174de907d4204dbc2ec98fe325 # bad: [0219641f7ec1bee5654f7b8c02d246fa27b03ab1] source-hash-9835fa87ac6ffe43bd9cc85839b2fea1fca2fcad git bisect bad 0219641f7ec1bee5654f7b8c02d246fa27b03ab1 # bad: [dbe3cc9b9a4b356f550657d57783c89bd293b46b] source-hash-e23806fb815f7e419bb04de11dcb5707c4120eaa git bisect bad dbe3cc9b9a4b356f550657d57783c89bd293b46b # bad: [0c6eb6d43e107345f59a3a09bd2c2577302819c2] source-hash-9cff642cd51bc70327789f9dc64349bb9b4cb3ea git bisect bad 0c6eb6d43e107345f59a3a09bd2c2577302819c2 # good: [7b9ad53b3ba4d291f49052ad9aee36b5cdcd4ac2] source-hash-9b62a5207745da6b926d2a311e5ddd16da1ae05b git bisect good 7b9ad53b3ba4d291f49052ad9aee36b5cdcd4ac2 # bad: [03feacde7d0d974d28adae78a32a9e0a85e68208] source-hash-d9b9f50242ece39f9ecbbb24128ae3eff4c3319e git bisect bad 03feacde7d0d974d28adae78a32a9e0a85e68208 # good: [1d95d38d2a260e012972c5d2ba4c6e1b0a64929c] source-hash-81c492ef18b04cc283561018d69818cbca7f83ef git bisect good 1d95d38d2a260e012972c5d2ba4c6e1b0a64929c # first bad commit: [03feacde7d0d974d28adae78a32a9e0a85e68208] source-hash-d9b9f50242ece39f9ecbbb24128ae3eff4c3319e
So if I read it right the fix is in this range: git log 81c492ef18b04cc283561018d69818cbca7f83ef..d9b9f50242ece39f9ecbbb24128ae3eff4c3319 I would guess this patch: https://issues.apache.org/ooo/show_bug.cgi?id=114361 commit 192abfb36b8a4859879fcb49326d59ed62083c8d Author: Oliver-Rainer Wittmann <orw@apache.org> Date: Mon May 19 11:37:11 2014 +0000 Resolves: #i114361# provide and accept changed URL... of embedded graphic file during save (ODF export) (cherry picked from commit a90c007908eb3f66e28a9ea525729065db652b6f) Is what fixed it (thanks to Oliver). Would love input on whether cherry-picking that to -4-3 fixes it for us. Andras - this one might be interesting for us too.
In libreoffice-4-3 we have http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3&id=51bc76f170c8fc71bc37c058c5e6cd1f14b773fb which is the backport of Oliver's commit a90c007908eb3f66e28a9ea525729065db652b6f. Further investigation is needed.
I tested the original files as our templates with logos (which got this error) on 4.3.6.2 and it WORKED fine (unlike previous 4.3.x versions) Also on 4.4.x that problem is NOT seen.
I can confirm this bug is no more on LO 4.4.1 with Win8.1 and Win7. Instead, it's only partially fixed in LO 4.3.6.2: some images loss and others correctly saved. Example ODT went down from 1.4 MB to 400 kb or so.
Migrating Whiteboard tags to Keywords: (filter:odt, DataLoss, bibisected) [NinjaEdit]