Bug Hunting Session
Bug 98500 - Multiple animated GIFs cause 100% CPU utilization in Impress
Summary: Multiple animated GIFs cause 100% CPU utilization in Impress
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
5.1.1.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, perf, regression
Depends on:
Blocks: Impress-Images
  Show dependency treegraph
 
Reported: 2016-03-07 15:01 UTC by Maris Nartiss
Modified: 2018-09-20 08:24 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Presentation with multiple animated GIFs causing LO Impress slowdown (4.56 MB, application/vnd.oasis.opendocument.presentation)
2016-03-07 15:01 UTC, Maris Nartiss
Details
Sample slides with animated gifs to demonstrate the problem (7.45 MB, application/vnd.oasis.opendocument.presentation)
2016-08-06 08:44 UTC, Dwokfur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Maris Nartiss 2016-03-07 15:01:31 UTC
Created attachment 123386 [details]
Presentation with multiple animated GIFs causing LO Impress slowdown

Even a small animated GIF causes Impress to slow down significantly. Having a presentation with multiple GIFs can cause Impress to rise CPU load to 100% eventually making impossible to edit the presentation.

Attachment contains a presentation that is not possible to edit on a Gentoo Linux ~AMD64 system running on a Core 2 Duo CPU 2.53GHz with 4Gb RAM. Although it is not a high-end system, editing a simple presentation with a few animations should be possible. Presentations without animated GIFs cause CPU load only in range of 10% (as reported by top).
An option to disable animations from running while in editing (not presentation) mode could be a workaround.

Steps to reproduce - on a Linux machine open attached sample and:
1) try to scroll down sidebar with slide previews (as soon as one animated slide enters field of view, CPU hits 100%);
2) try to edit (move around) any moving images from any of slides (5053 bogomips machine is too slow for that);
3) killall soffice.bin as you are tired of waiting till LO window will redraw itself to close it in a proper way.

Issue is still present on:
Version: 5.1.1.1
Build ID: c43cb650e9c145b181321ea547d38296db70f36e
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
Locale: lv-LV (lv_LV.utf8)

I was not able to observe any hight CPU utilisation with 5.0.0.5 (x64) running on a (more powerful) Windows 10 box - scrolling and editing of attached example file was snappy and without any hickups observed in Linux version.

Haven't been trying to trace back, but it has been present also in pre-5 versions, and no space for compilation to bisect. If it is required, I might try to install older binary versions to narrow down potential time of start of slowdown.

GDB output when Impress was consuming all you can eat CPU:
#0  0x00007f9fe4744766 in BitmapReadAccess::SetPixelFor_8BIT_PAL(unsigned char*, long, BitmapColor const&, ColorMask const&) () from /opt/libreoffice5.1/program/libmergedlo.so
#1  0x00007f9fe488a79a in GIFReader::FillImages(unsigned char*, unsigned long) ()
   from /opt/libreoffice5.1/program/libmergedlo.so
#2  0x00007f9fe488ab27 in GIFReader::ReadNextBlock() () from /opt/libreoffice5.1/program/libmergedlo.so
#3  0x00007f9fe488bb67 in GIFReader::ProcessGIF() () from /opt/libreoffice5.1/program/libmergedlo.so
#4  0x00007f9fe488beff in GIFReader::ReadGIF(Graphic&) () from /opt/libreoffice5.1/program/libmergedlo.so
#5  0x00007f9fe488c0a5 in ImportGIF(SvStream&, Graphic&) () from /opt/libreoffice5.1/program/libmergedlo.so
#6  0x00007f9fe48740f1 in GraphicFilter::ImportGraphic(Graphic&, rtl::OUString const&, SvStream&, unsigned short, unsigned short*, GraphicFilterImportFlags, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>*, WMF_EXTERNALHEADER*) () from /opt/libreoffice5.1/program/libmergedlo.so
#7  0x00007f9fe3f689d7 in SdrGrafObj::ImpSwapHdl(GraphicObject const*) ()
   from /opt/libreoffice5.1/program/libmergedlo.so
#8  0x00007f9fe3b658d0 in GraphicObject::ImplAutoSwapIn() () from /opt/libreoffice5.1/program/libmergedlo.so
#9  0x00007f9fe3f673e9 in SdrGrafObj::ForceSwapIn() const () from /opt/libreoffice5.1/program/libmergedlo.so
#10 0x00007f9fe3e91af4 in sdr::contact::ViewObjectContactOfGraphic::impPrepareGraphicWithAsynchroniousLoading() ()
   from /opt/libreoffice5.1/program/libmergedlo.so
#11 0x00007f9fe3e91d70 in sdr::contact::ViewObjectContactOfGraphic::createPrimitive2DSequence(sdr::contact::DisplayInfo const&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#12 0x00007f9fe3e95c00 in sdr::contact::ViewObjectContact::getPrimitive2DSequence(sdr::contact::DisplayInfo const&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#13 0x00007f9fe3e95f31 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceHierarchy(sdr::contact::DisplayInfo&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#14 0x00007f9fe3e95945 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceSubHierarchy(sdr::contact::DisplayInfo&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#15 0x00007f9fe3e77ea1 in sdr::contact::ViewObjectContactOfPageHierarchy::getPrimitive2DSequenceHierarchy(sdr::contact::DisplayInfo&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#16 0x00007f9fe3e95945 in sdr::contact::ViewObjectContact::getPrimitive2DSequenceSubHierarchy(sdr::contact::DisplayInfo&) const () from /opt/libreoffice5.1/program/libmergedlo.so
---Type <return> to continue, or q <return> to quit---
#17 0x00007f9fe3e781b6 in sdr::contact::ViewObjectContactOfSdrPage::getPrimitive2DSequenceHierarchy(sdr::contact::DisplayInfo&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#18 0x00007f9fe3e7bb52 in sdr::contact::PagePrimitiveExtractor::createPrimitive2DSequenceForPage(sdr::contact::DisplayInfo const&) () from /opt/libreoffice5.1/program/libmergedlo.so
#19 0x00007f9fe3e7c2e1 in sdr::contact::ViewObjectContactOfPageObj::createPrimitive2DSequence(sdr::contact::DisplayInfo const&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#20 0x00007f9fe3e95c00 in sdr::contact::ViewObjectContact::getPrimitive2DSequence(sdr::contact::DisplayInfo const&) const () from /opt/libreoffice5.1/program/libmergedlo.so
#21 0x00007f9fe3e967a3 in sdr::contact::ViewObjectContact::getObjectRange() const ()
   from /opt/libreoffice5.1/program/libmergedlo.so
#22 0x00007f9fe3e96a3d in sdr::contact::ViewObjectContact::triggerLazyInvalidate() ()
   from /opt/libreoffice5.1/program/libmergedlo.so
#23 0x00007f9fe3e96f89 in sdr::contact::ObjectContactOfPageView::Invoke() ()
   from /opt/libreoffice5.1/program/libmergedlo.so
#24 0x00007f9fe484fc58 in ImplSchedulerData::Invoke() () from /opt/libreoffice5.1/program/libmergedlo.so
#25 0x00007f9fe484fe65 in Scheduler::ProcessTaskScheduling(bool) ()
   from /opt/libreoffice5.1/program/libmergedlo.so
#26 0x00007f9fe485d206 in Application::Yield() () from /opt/libreoffice5.1/program/libmergedlo.so
#27 0x00007f9fe485ed05 in Application::Execute() () from /opt/libreoffice5.1/program/libmergedlo.so
#28 0x00007f9fe3960d06 in desktop::Desktop::Main() () from /opt/libreoffice5.1/program/libmergedlo.so
#29 0x00007f9fe4862c09 in ImplSVMain() () from /opt/libreoffice5.1/program/libmergedlo.so
#30 0x00007f9fe4862c52 in SVMain() () from /opt/libreoffice5.1/program/libmergedlo.so
#31 0x00007f9fe397e302 in soffice_main () from /opt/libreoffice5.1/program/libmergedlo.so
#32 0x000000000040075b in sal_main () at /home/buildslave/source/libo-core/desktop/source/app/main.c:48
#33 main (argc=<optimized out>, argv=<optimized out>)
    at /home/buildslave/source/libo-core/desktop/source/app/main.c:47
Comment 1 Robinson Tryon (qubit) 2016-03-11 22:25:32 UTC
TESTING with Ubuntu 14.04 +
LO 5.2.0.0.alpha0+ (2016-02-24_23:58:47)

(In reply to Maris Nartiss from comment #0)
> Steps to reproduce - on a Linux machine open attached sample and:
> 1) try to scroll down sidebar with slide previews (as soon as one animated
> slide enters field of view, CPU hits 100%);

NO REPRO on this slowdown: I tried scrolling down past all the slide thumbnails, and CPU never came close to 100%

> 2) try to edit (move around) any moving images from any of slides (5053
> bogomips machine is too slow for that);

Running through the slides, I *did* manage to crash LibreOffice 5.2 (master) twice, each time when loading a slide containing an animation. Couldn't repro the crash with LO 5.1.0.3, so it could just be a quirk of this 5.2 daily build.

TODO: Check with latest daily build of master. (I'm on a slow connection, so I can't grab a daily build today)
Comment 2 Buovjaga 2016-03-13 18:32:37 UTC
You don't need to compile to bisect :) https://wiki.documentfoundation.org/QA/Bibisect/Linux
For testing specific older versions: https://wiki.documentfoundation.org/Installing_in_parallel/Linux

When scrolling the thumbs, I only very briefly hit 100% CPU. I do have a i7 6700k Skylake.
Yet, going to slide 9 and clicking on the image brought about a massive slowdown and CPU screaming even over 100% at times.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.2.0.0.alpha0+
Build ID: 235411c9d47ecba88e46d859ea93bcecefb0c46e
CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)
Built on March 11th 2016
Comment 3 Armin Le Grand 2016-03-16 10:32:30 UTC
The GIF animations in the EditView are painted as regular repaint, thus it will directly depend on your repaint speed. That again depends on the rendering used behind the scenes. That again is greatly dependent on your distro.
All in all this has the potential to get better when the rendering in general is improved (Primitives and system-dependent primitive renderers). Currently not much to do...
Comment 4 Dwokfur 2016-08-06 08:44:05 UTC
Created attachment 126627 [details]
Sample slides with animated gifs to demonstrate the problem

I'm suffering from this bug for a long time now. It forced me to switch back to OO. Please take a look at on the sample slides I've uploaded. There's not so much problem I can see in EditView. Now try to enter into presentation mode. It gets unusable. Try switching slides: painfully slow. The animations are constantly lagging: they are jerky and lumpy. It happens to me using either x86 or x64 versions of LO 5.1.x or 5.2.x on Win 7 64bit. Also experience the same symptoms with LO x64 on Gentoo Linux 64bit - compiled from source. The same time OO 4.x binary performs well.
Now please load the same slides in OO 4.x or some old LO 4.x install! This is how it should do. The presentation is smooth and the transitions are nearly instant. The animations are well synchronized. This is a regression introduced long time ago and I wish it will be corrected, unless I cannot use this otherwise nice piece of software and should stick with OO 4.x or old LO installs.
Another remark: the background image looks pixelated in either EditView or during presentation. Just check out how much better it can be in OO 4.x or old LO.
I'm sorry to say, but LO 5.x Impress in its current form is simply useless to me and I'm quite worried about the future.
Please contact me, if I can help with testing some versions or stuff.
Comment 5 Buovjaga 2016-08-10 18:18:51 UTC
(In reply to Dwokfur from comment #4)
> Please contact me, if I can help with testing some versions or stuff.

If you want to help testing and analyzing bugs in general, there is nearly an infinite amount of work you can do. All the info is here: https://wiki.documentfoundation.org/QA
IRC is the most efficient way to coordinate things: https://wiki.documentfoundation.org/QA/IRC
Comment 6 Armin Le Grand 2016-08-26 15:28:36 UTC
@Dwokfur: AOO uses the same code - it's from me. Please confirm that it is faster.
Comment 7 Dwokfur 2016-08-28 15:33:59 UTC
(In reply to Armin Le Grand (CIB) from comment #6)
> @Dwokfur: AOO uses the same code - it's from me. Please confirm that it is
> faster.

@Armin: I've sent you an email with a link to page containing sample videos demonstrating the symptoms.
Note: the samples are happening on many computers at my workplace, not just the one I was demonstrating the issue.
Thank you for taking care of this: Dw.
Comment 8 Dwokfur 2016-08-31 21:45:33 UTC
(In reply to Armin Le Grand (CIB) from comment #6)
> @Dwokfur: AOO uses the same code - it's from me. Please confirm that it is
> faster.

Update to the bug based on Armin's questions:
It only occurs in presentation mode and not in edit mode. So something must be off in the presentation engine...
Comment 9 Armin Le Grand 2016-09-01 14:26:51 UTC
Discussed, only happens in presentation mode, NOT in edit mode.
Comment 10 Armin Le Grand 2016-09-01 14:27:41 UTC
Not sure what the presentation engine is using for playing GIFs, but is seems unadequate.
Comment 11 Maris Nartiss 2016-09-01 16:25:02 UTC
(In reply to Armin Le Grand (CIB) from comment #3)
> The GIF animations in the EditView are painted as regular repaint, thus it
> will directly depend on your repaint speed. That again depends on the
> rendering used behind the scenes. That again is greatly dependent on your
> distro.
> All in all this has the potential to get better when the rendering in
> general is improved (Primitives and system-dependent primitive renderers).
> Currently not much to do...

I tend to disagree. I installed an LO 4.x to test the same presentation. Although it was sluggish at the beginning, I was able to edit the last slide of my presentation - move around GIF, add text box with text, move it around etc. It only shows that much higher performance is possible as it was provided by an older version of LO.

Tested file: "Presentation with multiple animated GIFs causing LO Impress slowdown"
Tested versions (installed in parallel with identical settings - any hardware acceleration disabled):

Works quite good, although switching between animated slides in edit mode is with a delay (it takes time to load image).
Version: 4.4.7.2
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600

Epic Fail - after some minute of light editing of last slide, LO slowly gets unresponsive (window content is not repainted any more). Pauses between window content repaints get longer and longer till it is not possible to close LO in a normal way and killing it is the only option.
Version: 5.2.0.4
Build ID: 066b007f5ebcc236395c7d282ba488bca6720265
CPU Threads: 2; OS Version: Linux 4.7; UI Render: default;
Comment 12 Armin Le Grand 2016-09-02 08:03:46 UTC
> It only shows that much higher performance is possible as it was provided by
> an older version of LO.
Yes, but at the cost that these were not played in the Object-hierarchy, aka any object above it was overpainted by the anim-Gif. I think noone wants that back...
Comment 13 Maris Nartiss 2016-09-02 10:55:00 UTC
(In reply to Armin Le Grand (CIB) from comment #12)
> > It only shows that much higher performance is possible as it was provided by
> > an older version of LO.
> Yes, but at the cost that these were not played in the Object-hierarchy, aka
> any object above it was overpainted by the anim-Gif. I think noone wants
> that back...

In LO 4.4.7.2 I could add two overlapping animed GIFs + text boxes and other drawn figures in front and back of GIFs - partially overlapping them. No rendering issues in Edit or Presentation mode. I was able to edit the presentation (ok, slide switching is slow).

In LO 5.2 I even can not get that far to add second GIF, not talking about adding boxes etc.

If there is a choice between kill -9 soffice and objects ignoring rendering hierarchy, I fail to see any advantage of "the correct way of doing things".

If it helps to track the real issue, it seems that the condition is caused by hovering with mouse over animated GIF (a normal action while editing a slide). As long as there is no interaction with animated area, LO 5.2 is running fine.
Comment 14 Dwokfur 2016-09-02 12:23:40 UTC
(In reply to Armin Le Grand (CIB) from comment #12)
> > It only shows that much higher performance is possible as it was provided by
> > an older version of LO.
> Yes, but at the cost that these were not played in the Object-hierarchy, aka
> any object above it was overpainted by the anim-Gif. I think noone wants
> that back...

As I can make it out there are two separate problems mentioned here.
Maris has some problems in editview, while I have severe issues in presentation mode.
Should I open a separate bug?
Comment 15 Buovjaga 2016-12-20 19:50:28 UTC
*** Bug 104794 has been marked as a duplicate of this bug. ***
Comment 16 QA Administrators 2017-12-21 03:36:58 UTC Comment hidden (obsolete)
Comment 17 Dwokfur 2017-12-22 08:57:09 UTC Comment hidden (obsolete)
Comment 18 Telesto 2017-12-22 10:13:07 UTC
(In reply to Dwokfur from comment #4)
> Created attachment 126627 [details]
> Sample slides with animated gifs to demonstrate the problem

There is a new bug at this point, only 1 of 6 gif's is actually animated (bug 112997).
Comment 19 Telesto 2017-12-22 11:33:08 UTC
(In reply to Dwokfur from comment #14)
> As I can make it out there are two separate problems mentioned here.
> Maris has some problems in editview, while I have severe issues in
> presentation mode.
> Should I open a separate bug?

Please create a new bug, for the presentation mode issue and give clearly structured, to the point description (with only relevant info)of the issue  and the steps to reproduce the problem. 

Don't go into 'story' mode or add useless information like: "I've uploaded a sample slide previously anyone can use to make a headache to a machine running Libreoffice, especially on Windows. Please let me know if I can help with anything else." (comment 17) Thank you :-)
Comment 20 Dwokfur 2017-12-22 12:44:37 UTC
(In reply to Telesto from comment #19)
> (In reply to Dwokfur from comment #14)
> > As I can make it out there are two separate problems mentioned here.
> > Maris has some problems in editview, while I have severe issues in
> > presentation mode.
> > Should I open a separate bug?
> 
> Please create a new bug, for the presentation mode issue and give clearly
> structured, to the point description (with only relevant info)of the issue 
> and the steps to reproduce the problem. 
> 
> Don't go into 'story' mode or add useless information like: "I've uploaded a
> sample slide previously anyone can use to make a headache to a machine
> running Libreoffice, especially on Windows. Please let me know if I can help
> with anything else." (comment 17) Thank you :-)

Thank you for taking a look.
I opened a separate bug for the presentation mode: https://bugs.documentfoundation.org/show_bug.cgi?id=114647
Tried to avoid story telling mode as much as I could.
Comment 21 Maris Nartiss 2018-01-17 21:01:06 UTC
This is still an issue with 6.0.0.2.
Comment 22 Jean-Baptiste Faure 2018-04-14 19:41:58 UTC
*** Bug 117010 has been marked as a duplicate of this bug. ***
Comment 23 Buovjaga 2018-04-15 15:41:25 UTC
(In reply to Buovjaga from comment #2)
> When scrolling the thumbs, I only very briefly hit 100% CPU. I do have a i7
> 6700k Skylake.
> Yet, going to slide 9 and clicking on the image brought about a massive
> slowdown and CPU screaming even over 100% at times.

Was going to try to bibisect this, but now the problem seems to be solved.

Scrolling thumbs makes CPU peak at only 27%.
Clicking on image either in Notes or normal view does not cause any slowdown or huge CPU use.

Maris: could you try with version 6.1? https://wiki.documentfoundation.org/Installing_in_parallel/Linux

Arch Linux 64-bit
Version: 6.1.0.0.alpha0+
Build ID: c8c74a0b4ca6f3a3619f423b6548c80c52392ae0
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on April 15th 2018
Comment 24 Volga 2018-04-16 01:06:17 UTC
CC: Tomaz Vajngeri
Comment 25 Maris Nartiss 2018-04-16 16:06:30 UTC
(In reply to Buovjaga from comment #23)
> Was going to try to bibisect this, but now the problem seems to be solved.
> 
> Scrolling thumbs makes CPU peak at only 27%.
> Clicking on image either in Notes or normal view does not cause any slowdown
> or huge CPU use.
> 
> Maris: could you try with version 6.1?
> https://wiki.documentfoundation.org/Installing_in_parallel/Linux
> 
> Arch Linux 64-bit
> Version: 6.1.0.0.alpha0+
> Build ID: c8c74a0b4ca6f3a3619f423b6548c80c52392ae0
> CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: kde4; 
> Locale: fi-FI (fi_FI.UTF-8); Calc: group
> Built on April 15th 2018

Yes, for certain definitions of word "fixed".

The good:
* scrolling a presentation with animated GIFs is smooth
* moving animated GIF within slide with keyboard works fine

The bad:
* hovering over animated GIF in editing pane still causes LO UI to lock-up for some time (UI repaint takes seconds and happens line by line). As long as GIF image is not hovered over by the mouse cursor, LO runs fine.
* moving around animated GIF with mouse within the slide still is a game of patience (due to hovering) and now causes X11 to cause serious CPU load instead of LO. Still it is much better than it was.

And the ugly:
* closing LO Impress after an animated GIF has been hovered by the mouse cursor almost always ends with a LO crash. One of crashes managed to output a hint on "double free or corruption (fasttop)" in terminal.
* it is not always crashing while running under valgrind.


Version: 6.1.0.0.alpha0+
Build ID: dc823f5fa4a5d2eca56297b9045e5962536c00f9
CPU threads: 2; OS: Linux 4.16; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-10_23:32:35
Locale: lv-LV (lv_LV.utf8); Calc: group


==19701== Conditional jump or move depends on uninitialised value(s)
==19701==    at 0x14C9FA45: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD2E8B: X11SalGraphics::freeResources() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3150: X11SalGraphics::~X11SalGraphics() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3208: X11SalGraphics::~X11SalGraphics() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3F89: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD4008: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x7B10A50: VirtualDevice::dispose() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60FB34A: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60E719D: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60EA8B6: drawinglayer::primitive2d::Primitive2DContainer::~Primitive2DContainer() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60FEF4D: drawinglayer::primitive2d::GraphicPrimitive2D::~GraphicPrimitive2D() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60E719D: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701== 
==19701== Conditional jump or move depends on uninitialised value(s)
==19701==    at 0x4A09571: operator delete(void*) (vg_replace_malloc.c:576)
==19701==    by 0x14CD2E8B: X11SalGraphics::freeResources() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3150: X11SalGraphics::~X11SalGraphics() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3208: X11SalGraphics::~X11SalGraphics() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3F89: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD4008: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x7B10A50: VirtualDevice::dispose() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60FB34A: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60E719D: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60EA8B6: drawinglayer::primitive2d::Primitive2DContainer::~Primitive2DContainer() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60FEF4D: drawinglayer::primitive2d::GraphicPrimitive2D::~GraphicPrimitive2D() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60E719D: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701== 
==19701== Invalid free() / delete / delete[] / realloc()
==19701==    at 0x4A095BB: operator delete(void*) (vg_replace_malloc.c:576)
==19701==    by 0x14CD2E8B: X11SalGraphics::freeResources() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3150: X11SalGraphics::~X11SalGraphics() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3208: X11SalGraphics::~X11SalGraphics() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD3F89: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x14CD4008: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_genlo.so)
==19701==    by 0x7B10A50: VirtualDevice::dispose() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60FB34A: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60E719D: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60EA8B6: drawinglayer::primitive2d::Primitive2DContainer::~Primitive2DContainer() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60FEF4D: drawinglayer::primitive2d::GraphicPrimitive2D::~GraphicPrimitive2D() (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==    by 0x60E719D: ??? (in /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so)
==19701==  Address 0x2a2c7d90 is 0 bytes inside an unallocated block of size 128 in arena "client"


Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault.
0x0000000000000041 in ?? ()
#0  0x0000000000000041 in ?? ()
#1  0x00007ffff67ddda2 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#2  0x00007ffff6770912 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#3  0x00007ffff68add61 in Bitmap::~Bitmap() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#4  0x00007ffff4e6a2b6 in drawinglayer::primitive2d::BitmapPrimitive2D::~BitmapPrimitive2D() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program
/libmergedlo.so
#5  0x00007ffff4e792df in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#6  0x00007ffff4e6519e in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#7  0x00007ffff4e688b7 in drawinglayer::primitive2d::Primitive2DContainer::~Primitive2DContainer() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/p
rogram/libmergedlo.so
#8  0x00007ffff4e7cf4e in drawinglayer::primitive2d::GraphicPrimitive2D::~GraphicPrimitive2D() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/progr
am/libmergedlo.so
#9  0x00007ffff4e6519e in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#10 0x00007ffff4e688b7 in drawinglayer::primitive2d::Primitive2DContainer::~Primitive2DContainer() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/p
rogram/libmergedlo.so
#11 0x00007ffff5e80144 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#12 0x00007ffff4e6519e in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#13 0x00007ffff4e688b7 in drawinglayer::primitive2d::Primitive2DContainer::~Primitive2DContainer() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/p
rogram/libmergedlo.so
#14 0x00007ffff5e563b5 in sdr::contact::ViewContact::~ViewContact() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#15 0x00007ffff5e4c2e3 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#16 0x00007ffff5f2438f in SdrObject::~SdrObject() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#17 0x00007ffff5f39e6a in SdrGrafObj::~SdrGrafObj() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#18 0x00007ffff5f39f69 in SdrGrafObj::~SdrGrafObj() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#19 0x00007ffff5f2187b in SdrObject::Free(SdrObject*&) () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#20 0x00007ffff5f885ca in SdrObjList::Clear() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#21 0x00007fffd26c7be1 in SdPage::~SdPage() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#22 0x00007fffd26c7ea9 in SdPage::~SdPage() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#23 0x00007fffd26ac393 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#24 0x00007ffff5ef84ee in SdrModel::ClearModel(bool) () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#25 0x00007fffd26a4115 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#26 0x00007fffd26a4829 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#27 0x00007fffd27ce095 in sd::DrawDocShell::~DrawDocShell() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#28 0x00007fffd27ce3b9 in sd::DrawDocShell::~DrawDocShell() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#29 0x00007ffff58817f3 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#30 0x00007ffff5881c71 in SfxViewFrame::~SfxViewFrame() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#31 0x00007ffff58820a9 in SfxViewFrame::~SfxViewFrame() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#32 0x00007ffff587b6e1 in SfxViewFrame::Close() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#33 0x00007ffff585622d in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#34 0x00007ffff587055b in SfxBaseController::dispose() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#35 0x00007fffd2914b68 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/../program/libsdlo.so
#36 0x00007ffff51c46d0 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#37 0x00007ffff5110346 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#38 0x00007ffff511237f in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#39 0x00007ffff5112e61 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#40 0x00007ffff50d5b96 in framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatch> const&, com::sun::star::util::URL const&, bool, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#41 0x00007ffff50d71f5 in framework::DispatchHelper::executeDispatch(com::sun::star::uno::Reference<com::sun::star::frame::XDispatchProvider> const&, rtl::OUString const&, rtl::OUString const&, int, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#42 0x00007ffff5152a2c in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#43 0x00007ffff66d5b6a in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#44 0x00007ffff68e49ba in SalUserEventList::DispatchUserEvents(bool) () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#45 0x00007fffeab84828 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_kde4lo.so
#46 0x00007fffeab86680 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libvclplug_kde4lo.so
#47 0x00007ffff6900bae in Application::Yield() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#48 0x00007ffff69024a5 in Application::Execute() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#49 0x00007ffff58aeae9 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#50 0x00007ffff69077a6 in ?? () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#51 0x00007ffff6907892 in SVMain() () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#52 0x00007ffff58cf1ed in soffice_main () from /home/maris/tmp/LO/install/opt/libreofficedev6.1/program/libmergedlo.so
#53 0x000000000040075b in ?? ()
#54 0x0000003b39420f0a in __libc_start_main () from /lib64/libc.so.6
Comment 26 Buovjaga 2018-04-16 16:17:12 UTC
(In reply to Maris Nartiss from comment #25)
> The bad:
> * hovering over animated GIF in editing pane still causes LO UI to lock-up
> for some time (UI repaint takes seconds and happens line by line). As long
> as GIF image is not hovered over by the mouse cursor, LO runs fine.
> * moving around animated GIF with mouse within the slide still is a game of
> patience (due to hovering) and now causes X11 to cause serious CPU load
> instead of LO. Still it is much better than it was.

No lock-ups or crashes here. I will close this as the original issue is gone and I cannot repro this new stuff.

I recommend to give it some time and test again with a fresh master build (also under Safe mode). IF the lock-ups continue, open a new report.
Comment 27 Telesto 2018-04-16 17:37:49 UTC
> The bad:
> * hovering over animated GIF in editing pane still causes LO UI to lock-up
> for some time (UI repaint takes seconds and happens line by line). As long
> as GIF image is not hovered over by the mouse cursor, LO runs fine.

-> I observed the same for bug 104878
Comment 28 rickpress 2018-09-20 02:12:12 UTC
This bug still happens for me. 

Maybe it's computer specific? Only happens on certain computers?
Comment 29 Buovjaga 2018-09-20 08:24:24 UTC
(In reply to rickpress from comment #28)
> This bug still happens for me. 
> 
> Maybe it's computer specific? Only happens on certain computers?

It happened on my computer in 2016 as you can see from comment 2 but does not happen anymore.
Comment 4 described a different issue, but I cannot reproduce it either.
Bug 104878 is still open.
Let us leave this report in peace and open new ones for any further issues.