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
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)
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
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...
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.
(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
@Dwokfur: AOO uses the same code - it's from me. Please confirm that it is faster.
(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.
(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...
Discussed, only happens in presentation mode, NOT in edit mode.
Not sure what the presentation engine is using for playing GIFs, but is seems unadequate.
(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;
> 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 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.
(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?
*** Bug 104794 has been marked as a duplicate of this bug. ***
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #16) > ** Please read this message in its entirety before responding ** > MassPing-UntouchedBug I'd like to confirm, that I still experience the symptoms on my behalf. There are two issues mentioned in this bug. One issue is the behavior while editing the slides. My problems show up in presentation mode. The whole story escalated by the advent of version 5.x, version 4.x and before is fine. In editing mode you could see multiple animgifs playing at the same time without any problems both while editing the slides or during presentation. After version 5.x came out, either only the upper left animgif plays during editing or none of them at all (this is just like Microsoft Office, where you can only see animgifs playing in presentation mode). If I start the presentation on Windows 7 Pro or Enterprise 64bit, Libreoffice starts consuming CPU resources and hangs, but doesn't crash. Unexperienced users may not be able to recover from this situation. You have to change tasks and force Libreoffice to exit. Version: 5.4.3.2 (x64) Build ID: 92a7159f7e4af62137622921e809f8546db437e5 CPU threads: 8; OS: Windows 6.1; UI render: GL; Locale: hu-HU (hu_HU); Calc: group This keeps me using Libreoffice on Windows for the past two years or so. I use Openoffice, which is still using version 4.x type rendering for animgifs. I also use Libreoffice on Linux, where I compile it from source on Gentoo. That instance of the software behaves better in presentation mode. Things got better on Linux over the past two years. It tend to hang like on Windows before, but now it plays the slides well enough. Linux version use different redering backend definitely. Version: 5.4.3.2 Build ID: Gentoo official package CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: gtk3; Locale: hu-HU (hu_HU.utf8); Calc: group 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. As version 6 is coming out, I will retest the situation. I can easily hack on windows, since I'm using a rolling distro but not on windows. Which is kind of unfortunate, since the symptoms are primarly affecting Windows version of Libreoffice. I would be so happy to see this problem go away. Thanks: Dwokfur
(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).
(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 :-)
(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.
This is still an issue with 6.0.0.2.
*** Bug 117010 has been marked as a duplicate of this bug. ***
(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
CC: Tomaz Vajngeri
(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
(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.
> 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
This bug still happens for me. Maybe it's computer specific? Only happens on certain computers?
(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.