Created attachment 120301 [details] Video I see another bug similar but for another writer version. I always use linked images. They are on the local drive. When open or scrolling within the document, sooner or later it happens the image-frames begin flickering alternate showing 'Read error' and the path. The document freezes (see attached image). No chance to continue. I have to kill the swriter-process. Most of time this happens at the moment moving between the pages. With 4.4.X and earlier i didn't experience this problem, also with documents containing a lot of images. WINDOWS 7 64 WINDOWS 10 64
Created attachment 120303 [details] Actual version instaled
Hi Pedro - Can you please attach a zip file that has a couple images linked to an odt that we can test with. Setting to NEEDINFO. Once you attach please set the bug back to UNCONFIRMED. Thanks
Hi Joel, I send a document with the problem by email. Thanks.
Created attachment 120435 [details] bugdoc (ODT) Open the attached bugdoc and put the attached image next to it. Open the bugdoc and scroll to page 2. See the flickering/read error. "warn:legacy.osl:18567:1:sw/source/core/graphic/ndgrf.cxx:594: Cannot swap in graphic" messages are printed endlessly in dbgutil build.
Created attachment 120436 [details] put this next to bugdoc (a linked image)
I see this on Linux, too...
Created attachment 120460 [details] Document with multiples images
If this is related to the idle re-work, then (almost inevitably) this is a starvation problem. Whereby one idle handler relies on another one to be triggered - and yet that other handler has a lower priority (or somesuch) so we never get to it. I would put some breakpoints into ImplSchedulerData::Invoke() to see what is going on there =) thanks !
a fix: https://gerrit.libreoffice.org/#/c/19974/
I have updated the patch with a better - not final - version to show, that the problem is the unlimited asynchronous loading of the same linked image(s), resulting continuous releasing in graphic cache and unfinished page redraws (stack traces attached). I will update the patch with an unordered_map to recognize all undesirable repeated image loadings (the draft version fixes only the bugdoc).
Created attachment 120588 [details] paint stack trace
Created attachment 120589 [details] graphic cache stack trace
I have updated the gerrit patch using an unordered_set to avoid repeated asynchronous loading of the same pictures in the same document, solving the livelocks in both test documents.
László Németh committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=58e2a9efe554ff2ac09a902d13a18e954487b672 tdf#95614 fix freezing with linked images It will be available in 5.1.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8169a821c40ee4b0c427f5c2e9b7fa6ab3b4536 Revert "tdf#95614 fix freezing with linked images" It will be available in 5.1.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.
Created attachment 120738 [details] Second LoadFile_Impl() call of an asynchronous image loading
I downloaded the dev version of the program and the problem persists.
Created attachment 120825 [details] Dev version
The problem solved in the master/LO 5.1 with the new scheduler fixes. I have updated the gerrit with the following optional fix: https://gerrit.libreoffice.org/#/c/19974/, When an unloaded linked picture comes into the visible view (including repainting a page), SwNoTextFrm::PaintPicture() starts a thread to load it in the background using the TriggerAsyncRetrieveInputStream() method of the graphic node. To avoid to start a second thread on the same graphic node, TriggerAsyncRetrieveInputStream() checks mpThreadConsumer, the graphic node member variable for the possible thread object. The problem is that when the thread finished and SwGrfNode::UpdateLinkWithInputStream() reset mpThreadConsumer, the graphic object of the graphic node is still in unloaded state (its type is GRAPHIC_DEFAULT or GRAPHIC_NONE instead of GRAPHIC_BITMAP or GRAPHIC_GDIMETAFILE) for a while, because its modification is solved asynchronously after several SvFileObject::GetData() calls. In the intermediate state of the graphic object, with the high priority repaints of the new scheduler, PaintPicture() could start new thread to load the image again. Using the new member variable SwGrfNode::mbUpdateLinkInProgress, this patch will prevent the graphic node to start newer thread unnecessarily.
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=945da612c70cc67c3b182c3f2ecdfd4333c8f456&h=libreoffice-5-0 tdf#95614 fix freezing with linked graphic It will be available in 5.0.5. 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.
Migrating Whiteboard tags to Keywords: (regression)
*** Bug 88845 has been marked as a duplicate of this bug. ***
Hi. Bug 97786 (https://bugs.documentfoundation.org/show_bug.cgi?id=97786) seems to be a duplicate of this bug. I still experience the "read error, flickering, freeze" behaviour in LO 5.0.5.2 and LO 5.1.0.3 (Windows 7, 64). It is worse if the image files are bigger. Using Writer with more than a couple of linked images is now completely impossible. Thanks and all the best, Pedro
Same problem in Libre Office 5.1.0.3; No problem in docs with less then three pictures.
*** Bug 97786 has been marked as a duplicate of this bug. ***
I can no longer reproduce this problem using attachment #120460 [details] in Version: 5.3.0.0.alpha0+ Build ID: 8974b0fafb18f9dd3f2c0e175a3255b80e4c249e CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; Locale: ca-ES (ca_ES.UTF-8); Calc: group closing it as RESOLVED WORKSFORME