Bug 101294 - LibreOffice Deadlocks On Font Change On Some Documents
Summary: LibreOffice Deadlocks On Font Change On Some Documents
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, needsDevAdvice
Depends on:
Blocks:
 
Reported: 2016-08-04 14:00 UTC by Dave Richards
Modified: 2017-10-24 19:33 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Document open, do a SelectAll (205.02 KB, image/jpeg)
2016-08-04 14:00 UTC, Dave Richards
Details
The text is selected (203.32 KB, image/jpeg)
2016-08-04 14:01 UTC, Dave Richards
Details
Click the dropdown menu, fonts display, and allow me to pick one (211.39 KB, image/jpeg)
2016-08-04 14:01 UTC, Dave Richards
Details
and LibreOffice deadlocks, the canvas stops repainting and editing is no longer allowed (187.14 KB, image/jpeg)
2016-08-04 14:02 UTC, Dave Richards
Details
The document in question (137.09 KB, application/vnd.oasis.opendocument.text)
2016-08-04 14:02 UTC, Dave Richards
Details
thread apply all bt at the point of deadlock (17.08 KB, text/plain)
2016-08-04 14:10 UTC, Dave Richards
Details
Strace Log Of Font Change And Lock (2.88 MB, text/plain)
2016-08-08 12:35 UTC, Dave Richards
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Richards 2016-08-04 14:00:10 UTC
After many months of trying to replicate this issue and it affecting us greatly, I finally got a document that demonstrates this issue clearly.  We have been getting reports that LibreOffice deadlocks when changing fonts in a small minority of our documents.  I will be attaching the document in question, along with screenshots of the deadlock as it happens.

I looked at the source xml files inside this odt and it does seem to have fonts for Linux and Windows, that it's been edited on both platforms.

There are some complexities, this only seems to happen on OpenSuse 11.4, which as it turns out is your production operating system for our users for the next few months until upgrades can be staged.  This does not happen on Ubuntu, which have allowed me to bibisect this and find the exact commit.

I have easily replicated this issue on all of our OpenSuse 11.4 servers.  I have found that version 4.4 works fine, but the bug was introduced in version 5.0

It's still happening on master, so I downloaded the -dbg version and will upload a backtrace of where the deadlock is happening.

To replicate the issue, I open one of these documents and then do a Select All, and then pick one of the fonts from the dropdown menu and the dropdown menu section of the canvas fails to repaint and LO is essentially deadlocked.

One interesting caveat, is that if you have a favorite font at the top of the dropdown menu, and pick that one it works. But any other font causes it to deadlock.
Comment 1 Dave Richards 2016-08-04 14:00:55 UTC
Created attachment 126580 [details]
Document open, do a SelectAll
Comment 2 Dave Richards 2016-08-04 14:01:15 UTC
Created attachment 126581 [details]
The text is selected
Comment 3 Dave Richards 2016-08-04 14:01:51 UTC
Created attachment 126582 [details]
Click the dropdown menu, fonts display, and allow me to pick one
Comment 4 Dave Richards 2016-08-04 14:02:28 UTC
Created attachment 126583 [details]
and LibreOffice deadlocks, the canvas stops repainting and editing is no longer allowed
Comment 5 Dave Richards 2016-08-04 14:02:57 UTC
Created attachment 126584 [details]
The document in question
Comment 6 Dave Richards 2016-08-04 14:10:16 UTC
Created attachment 126585 [details]
thread apply all bt at the point of deadlock
Comment 7 Yousuf Philips (jay) (retired) 2016-08-05 19:56:43 UTC
Cant reproduce on linux mint and doubt anyone from the team will be able to reproduce it either as non are on opensuse that i know of. :(

Version: 5.3.0.0.alpha0+
Build ID: 8da4ba9be2d2deb8990f40fa0cc5d6b16d525c72
CPU Threads: 2; OS Version: Linux 3.19; UI Render: default; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-08-03_23:43:46
Locale: en-US (en_US.UTF-8); Calc: group
Comment 8 Dave Richards 2016-08-08 12:35:39 UTC
Created attachment 126669 [details]
Strace Log Of Font Change And Lock
Comment 9 Dave Richards 2016-08-08 17:26:00 UTC
Ok, I just found that setting SAL_USE_VCLPLUGIN=gen does not exhibit this bug, but when I put it back to gkt2 (or gtk3), the bug happens again.  The X11 (gen) interface is pretty awful, but does not lock when the font is changed.  So this bug seems to be in some way related to GTK.
Comment 10 Jan-Marek Glogowski 2016-08-25 17:24:00 UTC
[18:36] <dave_largo> It is fixed on new version of GTK and only impacts us on OpenSuse 11.4, so it might not be worth the effort
[18:40] <jmux> dave_largo: if you already know, it's a Gtk+ error, why don't you backport a newer Gtk+ version?
[18:41] <dave_largo> There just aren't resources for that, and if this VCL thing works, I can limp along for a few months.
[18:47] <jmux> dave_largo: And the backtrace actually looks fishy - Application::Yield () calls ImplYield (i_bWait=false… - that shouldn't be possible
[18:48] <dave_largo> jmux: What happens is that after the font changes, the UI is running at 5% speed, appears deadlocked to users.  And it seems to only happen if fonts are in the style that do not exist locally
[18:50] <jmux> dave_largo: and I guess the process itself uses 100% CPU. From the backtrace I would even guess you have a memory corruption.
[18:51] <jmux> The only thing Application::Yield () does is call ImplYield(true, false, 0);
[18:51] <jmux> Now your backtrace says #13 0x00007fd1f31a9455 in ImplYield (i_bWait=false,
[18:52] <jmux> #14 0x00007fd1f31a5356 in Application::Yield ()
[18:53] <jmux> That's quite probably not fixable in LO, especially if you already know a newer SuSE version (it doesn't need to be Gtk+) works correct.
...
[19:13] <jmux> dave_largo: BTW - which LO version are you using?
[19:15] <dave_largo> jmux: Most are on 5.2, a few on 5.3.   This bug is in 5.0, 5.1. 5.2 and 5.3.  In 4.3 it works fine.

So the code on master AKA 5.3 for Application:Yield is

void Application::Yield()
{
    ImplYield(true, false, 0);
}

but the backtrace is 

#13 0x00007fd1f31a9455 in ImplYield (i_bWait=false,…
#14 0x00007fd1f31a5356 in Application::Yield ()

Looks like a memory corruption.

And as the reporter has written, it's fixed on a newer SuSE version, which suggests it's not a direct LO problem.
Comment 11 julien 2016-09-02 21:17:19 UTC
Hello,

I can confirm this bug with Libreoffice 5.2.0 (from libreoffice.org) on Mageia 5.

The symptoms are the same and the test with SAL_USE_VCLPLUGIN=gen doesn't produce the bug. Reproductible with the file attached to this bug or a file I've got on my computer (can attach it if it would help).

In my case, the bug appears if I don't have the fonts used by the document (e.g. calibri) and I try to change it.

I can also reproduce with libreoffice 5.2.0 x86_64 on Mageia 6 (in development) using the file attached.

LibreOffice 5.2.0 x86_64

Mageia 5
lib64gtk+3_0-3.14.8-5.1.mga5
lib64gtk+2.0_0-2.24.26-3.mga5

Mageia 6
lib64gtk+3_0-3.20.9-1.mga6
lib64gtk+2.0_0-2.24.30-1.mga6

Let me know if you need more information.
regards
Julien
Comment 12 Dave Richards 2016-09-06 19:40:15 UTC
@julien, any chance that the bibisect tools run on your flavor of Linux?  I was not able to get them running on OpenSuse 11.4 because it's too old.
Comment 13 Jean-Baptiste Faure 2016-10-02 09:09:05 UTC
Not reproducible for me with LO 5.2.3.0+ under Ubuntu 16.04 x86-64.
That said, according to comment #12, status set to NEW.

Best regards. JBF
Comment 14 julien 2016-10-09 19:33:47 UTC
(In reply to Dave Richards from comment #12)
> @julien, any chance that the bibisect tools run on your flavor of Linux?  I
> was not able to get them running on OpenSuse 11.4 because it's too old.

I just realized, I'm not CC on this bug (thought it was automatic). I will try to bibisect ASAP.

More information, I tested with the version compiled by my distribution on mageia6 (5.2.2 today) and the bug doesn't appear with it whereas it is present with the version from libreoffice.org

regards
Julien
Comment 15 julien 2016-10-10 19:26:22 UTC
(In reply to Dave Richards from comment #12)
> @julien, any chance that the bibisect tools run on your flavor of Linux?  I
> was not able to get them running on OpenSuse 11.4 because it's too old.

Ok, I tried to bibisect but can't reproduce the bug with a debug build whereas the same version "release built" exhibit the bug :-/

sorry
regards
Julien
Comment 16 QA Administrators 2017-10-23 13:57:45 UTC Comment hidden (obsolete)
Comment 17 julien 2017-10-24 19:33:21 UTC
Hello,

following the mass ping, I retested with multiples versions of LO on mageia 6 x86_64 and the bug is fixed here :

in LO 5.4 all versions

in LO 5.3 all versions

in LO 5.2 since 5.2.3 :
Version: 5.2.3.3
Build ID: d54a8868f08a7b39642414cf2c8ef2f228f780cf
CPU Threads: 4; OS Version: Linux 4.9; UI Render: default; 
Locale: fr-FR (fr_FR.utf8); Calc: group

Good job 

regards
Julien