[Libreoffice-bugs] [Bug 99519] New: Impress Crashes When Animated GIF added to presentation

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

Bug ID: 99519
Summary: Impress Crashes When Animated GIF added to
presentation
Product: LibreOffice
Version: unspecified
Hardware: Other
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Impress
Assignee: libreoffice-***@lists.freedesktop.org
Reporter: ***@hotmail.com

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

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

turboboost17 <***@hotmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Version|unspecified |5.1.1.3 release

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

raal <***@post.cz> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |regression
CC| |***@post.cz

--- Comment #1 from raal <***@post.cz> ---
Please attach GIF image which crashes Impress. Thank you

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

raal <***@post.cz> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEEDINFO
Ever confirmed|0 |1

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

--- Comment #2 from turboboost17 <***@hotmail.com> ---
Created attachment 125206
--> https://bugs.documentfoundation.org/attachment.cgi?id=125206&action=edit
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

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

--- Comment #3 from turboboost17 <***@hotmail.com> ---
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

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

turboboost17 <***@hotmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |UNCONFIRMED
Ever confirmed|1 |0

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

Buovjaga <***@suomi24.fi> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@suomi24.fi

--- Comment #4 from Buovjaga <***@suomi24.fi> ---
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)

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

--- Comment #5 from turboboost17 <***@hotmail.com> ---
Created attachment 125301
--> https://bugs.documentfoundation.org/attachment.cgi?id=125301&action=edit
Error screen

This is the error screen that appears when Impress fails

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

--- Comment #6 from turboboost17 <***@hotmail.com> ---
Reproduced the error with different Win7 machine and Impress 5.0.0.5

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

Aron Budea <***@caesar.elte.hu> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords|regression |
Status|UNCONFIRMED |NEW
CC| |***@caesar.elte.hu
Component|Impress |graphics stack
Version|5.1.1.3 release |Inherited From OOo
Ever confirmed|0 |1

--- Comment #7 from Aron Budea <***@caesar.elte.hu> ---
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?

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

--- Comment #8 from Buovjaga <***@suomi24.fi> ---
(In reply to Aron Budea from comment #7)

Post by b***@bugs.documentfoundation.org
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

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

Caolán McNamara <***@redhat.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@redhat.com

--- Comment #10 from Caolán McNamara <***@redhat.com> ---
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

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

Buovjaga <***@suomi24.fi> changed:

What |Removed |Added
----------------------------------------------------------------------------
Keywords| |perf
Summary|Impress Crashes When |Extremely high memory
|Animated GIF added to |usage, sometimes crash when
|presentation |animated GIF is inserted
OS|Windows (All) |All
Severity|normal |major

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

--- Comment #9 from Aron Budea <***@caesar.elte.hu> ---
(In reply to Buovjaga from comment #8)

Post by b***@bugs.documentfoundation.org
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)

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

--- Comment #11 from Armin Le Grand (CIB) <***@me.com> ---
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'

[b***@bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=99519

Armin Le Grand (CIB) <***@me.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|libreoffice-***@lists.free |***@me.com
|desktop.org |

--- Comment #12 from Armin Le Grand (CIB) <***@me.com> ---
1st version on gerrit, added flag for very big AnimatedGIFs to handle special,
commented in commit how to possibly do better in the future