When any GIF larger than a few MB is added to a presentation the program crashes. This a new bug as of the last 2 years or so because it did not happen 2 summers ago. I've updated the last few versions and it has not been fixed so far. FYI
Please attach GIF image which crashes Impress. Thank you
Created attachment 125206 [details] Large gif Large motion gif that crashes Impress when added to Presentation with a thread error "Fatal Error", osl::Thread::create failed. Gif's larger than 2MB may crash Impress. Much greater than 1MB may freeze or lag especially during dual screen presentation. This file works flawlessly in powerpoint 2016
Large motion gif that crashes Impress when added to Presentation with a thread error "Fatal Error", osl::Thread::create failed. Gif's larger than 2MB may crash Impress. Much greater than 1MB may freeze or lag especially during dual screen presentation. This file works flawlessly in powerpoint 2016
No repro. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: 60041cb237ea73c2c1885dd6afd99d88780c2dfc CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on May 26th 2016 64-bit, KDE Plasma 5 Build ID: 5.1.3.2 Arch Linux build-1 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8)
Created attachment 125301 [details] Error screen This is the error screen that appears when Impress fails
Reproduced the error with different Win7 machine and Impress 5.0.0.5
I could reproduce this in LO 5.1.3.2/Windows 7, and with earlier ones as well, back to 3.3. Also with master build. When the image is inserted, the memory consumed by soffice.bin rapidly starts to grow, on my machine the error screen attached in Comment 5 appears in less than 30 seconds at ~1.5 GB memory usage. In the early LO versions the growing stops at ~1.3-1.4 GBs, the animation plays for a bit, and then disappears. I'd say the high resource consumption with this particular gif is not a regression, and can also be observed in Writer => adjusting component to graphics stack. Just noting that trying to reproduce it crashed my Ubuntu VM (with a modest 2 GB memory limit), does that count as reproducible? :) Buovjaga, what's the resource usage in your system after inserting the image?
(In reply to Aron Budea from comment #7) > Buovjaga, what's the resource usage in your system after inserting the image? htop says 11.3% when the memory use climbing stops. I have 32GB of memory. Arch Linux 64-bit, KDE Plasma 5 Version: 5.3.0.0.alpha0+ Build ID: ab0189433c1593c3c3ccf6a947aa7ba84e806d91 CPU Threads: 8; OS Version: Linux 4.5; UI Render: default; Locale: fi-FI (fi_FI.UTF-8) Built on May 28th 2016
(In reply to Buovjaga from comment #8) > htop says 11.3% when the memory use climbing stops. I have 32GB of memory. 11% of 32GB sounds like a lot to me... do you think this warrants Linux being included among the affected systems, with a reworked title? (something like: Extremely high memory usage, sometimes crash when animated GIF is inserted)
This .gif is an 8 bit 1920x1080 animated gif with 382 frames in it, and indeed on my debugging master LibreOffice when it is rendering "top" reports... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 16063 caolan 20 0 4843764 3.580g 174440 S 30.3 11.4 0:27.83 soffice.bin some debugging shows that in drawinglayer/source/primitive2d/graphicprimitivehelper2d.cxx when we have an animated gif we render each frame into a separate BitmapEx and create a BitmapPrimitive2D for each one and the size balloons once rendering starts and generates 382 of those. With my proposed fix of https://gerrit.libreoffice.org/25671 to add a custom AnimationFrameBitmapPrimitive2D which shares a virtual device among the frames of a animated gif and moves the BitmapEx generation around to become on-demand I then get those numbers down to... PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15438 caolan 20 0 1733572 569528 174276 R 82.2 1.7 0:24.75 soffice.bin
Working on a solution to - have stuff isdolated ina single primitive - have a primitive directly specialized/derived from AnaimatedSwitchPrimitive - have no shared VirtualDevices over multiple primitives - have a central place to manage buffering/no buffering Problem is that when not buffering (but creating frames on-demand) performance is bad - a single GIF uses 100% CPU time (debug, but bad). That is clear - with BitmapEx and two VirtualDevices involved too many graphic format conversions take place (CPU pixel OP's). That is exactly why the frames *are* completely prepared as BitmapEx frames/Primitives. Target now is to - always buffer 1st frame (Caolan already found out that it is requested out-of-order sometimes) - decide to buffer or not based on animated GIF size - have the future option to have ths as 'recreatable, flushable ressource'
1st version on gerrit, added flag for very big AnimatedGIFs to handle special, commented in commit how to possibly do better in the future
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=285744fef87f4ca0278834b97d7f618bdba5f4c0 tdf#99519 Added more intelligent handling of animated GIFs It will be available in 5.3.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.
Armin Le Grand committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=702b58945b51e738cdcc3d383ca38881f9f1338d&h=libreoffice-5-2 tdf#99519 Added more intelligent handling of animated GIFs It will be available in 5.2.0.1. 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.