Bug 35270 - LibreOffice hangs when it loads LanguageTool for the first time
Summary: LibreOffice hangs when it loads LanguageTool for the first time
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Linguistic (show other bugs)
(earliest affected)
3.5.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
Whiteboard: target:3.6.0 target:3.5.4
Depends on:
Reported: 2011-03-13 06:52 UTC by szotsaki
Modified: 2012-06-04 10:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description szotsaki 2011-03-13 06:52:07 UTC
In either Writer or Calc when I open an existing, non-empty document it hangs for about 15 seconds until it loads the spell checker.

If I turn that feature off the document loads swift next time. And it hangs again at that moment I turn that on.
Comment 1 Yifan Jiang 2011-03-15 02:54:52 UTC
Hi szotsaki, would you attach the file caused the problem? I didn't see this issue in my environment.
Comment 2 Yifan Jiang 2011-03-15 02:59:10 UTC
Ah, just realized may be the language tool causes the issue, how about the performance after removing languagetool packages? Thanks!
Comment 3 szotsaki 2011-03-17 04:38:20 UTC
On openSUSE 11.4 I removed the libreoffice-languagetool and libreoffice-languagetool-en packages. There's no Hungarian variant of these.

Interestingly, after removing these two packages the Hungarian spell-checker is still working and the performance issues are addressed. So, there's no slowdown.
Comment 4 Björn Michaelsen 2011-12-23 11:52:39 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 5 Björn Michaelsen 2011-12-23 17:02:01 UTC
needinfo keyword redundant by needinfo status.
Comment 6 szotsaki 2011-12-29 05:52:53 UTC
As soon as I will upgrade to 3.5 final version with the help of my distribution's package manager, I'll recheck this bug.
Comment 7 Daniel Naber 2012-04-28 15:48:11 UTC
I have finally come up with a detailed analysis: on each startup, the slow method SvxLinguConfigUpdate::UpdateAll() is called. A comment in the code suggests that this isn't needed anymore. Can we change the code like the comment suggests in unolingu.cxx, line 395? Namely using

aAny <<= nCurrentDataFilesChangedCheckValue;

instead of

aAny <<= (sal_Int32) -1;    // keep the value set to 'need to check'

I have tested that this fixes the issue that this bug report is about.

Here's in detail what happens on startup:

doclay.cxx calls (*pLayIter)->GetCurrShell()->LayoutIdle();
layact.cxx calls ((SwTxtFrm*)pCnt)->_AutoSpell( pCntntNode,  *pSh->GetViewOptions(), nTxtPos );
txtedt.cxx calls bSpell = xSpell.is() ? xSpell->hasLanguage( eActLang ) : sal_False;
unolingu.cxx calls SpellDummy_Impl::GetSpell_Impl()
finally, SpellDummy_Impl::GetSpell_Impl() calls this:

    if (SvxLinguConfigUpdate::IsNeedUpdateAll())

IsNeedUpdateAll() will return true, because aLinguOpt.nDataFilesChangedCheckValue is -1 because SvxLinguConfigUpdate::UpdateAll() will set it to -1, with a comment that this is only needed for <= OOo 3.0
("for the time being (developer builds until OOo 3.0)..."). Thus after each startup, SvxLinguConfigUpdate::UpdateAll() gets called which takes a few seconds and blocks the machine.

Another questions is why SvxLinguConfigUpdate::UpdateAll() is so slow and blocks. I haven't checked that out, as the change above fixes the problem. I have increased the 'version' property of this bug report because it also affects the latest version.
Comment 8 Daniel Naber 2012-04-29 04:52:20 UTC
For reference, here's the comment from unolingu.cxx I was talking about above:

        // for the time being (developer builds until OOo 3.0)
        // we should always check for everything available
        // otherwise we may miss a new installed extension dicitonary
        // just because e.g. the spellchecker is not asked what
        // languages it does support currently...
        // Since the check is on-demand occuring and executed once it should
        // not be too troublesome.
        // In OOo 3.0 we will not need the respective code anymore at all.
//      aAny <<= nCurrentDataFilesChangedCheckValue;
        aAny <<= (sal_Int32) -1;    // keep the value set to 'need to check'

Further testing unfortunately reveals that it applies to current builds, too (despite saying "builds until OOo 3.0"). So if you use "aAny <<= nCurrentDataFilesChangedCheckValue", newly installed dictionary extentions will not be recognized until you restart LO. By "not recognized" I mean that the checkmarks do not appear on the language in the language drop down.

Another potential solution for the original problem might be in lngsvcmgr.cxx, LngSvcMgr::getAvailableServices(). It says:

        // don't used cached data here (force re-evaluation in order to have downloaded dictionaries
        // already found without the need to restart the office
        delete pAvailGrammarSvcs;  pAvailGrammarSvcs = 0;

Commenting out that line makes SvxLinguConfigUpdate::UpdateAll() quite fast so the original problem is gone. Grammar checkers need a restart of LO anyway, so I think the cache could be used here.

Trying to debug this issue, I also found you can solve it by just commenting out (*pLayIter)->GetCurrShell()->LayoutIdle(); in doclay.cxx in the if (pTmpRoot->IsNeedGrammarCheck()) block. That code was committed on 2010-06-13. As I'm just debugging and I don't know much about LO internals I have no idea what the side effects of removing that code might be, but everything worked fine for me at a first glance.
Comment 9 Michael Meeks 2012-05-11 12:48:41 UTC
> I also found you can solve it by just commenting out 
> (*pLayIter)->GetCurrShell()->LayoutIdle(); in doclay.cxx in
> the if (pTmpRoot->IsNeedGrammarCheck()) block.

I poked at that - it seems that just disables the execution of the idle handlers one of which loads the checker; so - I'm more interested in the lower level pieces you identify :-) digging there currently ...
Comment 10 Michael Meeks 2012-05-14 05:35:01 UTC
More debugging - it -seems- that part of our problem is that we install dictionaries (etc.) for a ton of languages, which then in turn provokes all this silliness in editeng :-)

Having said that - there really seems like no excuse for not using the cache there - the original commit commenting out that stuff read:

    INTEGRATION: CWS oolinguforso (1.25.18); FILE MERGED
    2006/12/18 09:23:06 tl #130176# have OOo download dictionaries functional without restart

But the issue is an obsolete / internal Sun bug ticket which we have no access to now; testing this download/install dictionaries and making that work nicely seems a bit of a royal pain as well.
Comment 11 Not Assigned 2012-05-14 06:48:27 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "master":


fdo#35270 - enable caching of grammar checker properties
Comment 12 Michael Meeks 2012-05-14 09:29:00 UTC
I'll knock up an easy-hack to fix the tangled awfulness that is the editeng / linguistic interaction in a bit :-)

Thanks so much for looking into this Daniel ! it's in the review queue for 3.5.4 (rc1 due next week).
Comment 13 Not Assigned 2012-05-15 02:55:55 UTC
Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":


fdo#35270 - enable caching of grammar checker properties

It will be available in LibreOffice 3.5.4.