[Upstream] openjdk-7 slows LibreOffice a lot and causes it to crash

[Indian Art]

openjdk-7 slows LibreOffice (LO) a lot and causes it to freeze/ hang very frequently. LO boots in seconds when openjdk-7 is not used. LO is very stable & does not hang when openjdk-7 is not used. I did not have any problems with LO in the previous version of Ubuntu (11.10).

Unfortunately, I cannot 'live' without openjdk-7 as it is needed in some LO extensions that I used every single day. For example, LanguageTool & OpenOffice.org2GoogleDocs.

I have attached some error logs.

Ubuntu Release 12.04 (precise) 32-bit
Kernel Linux 3.2.0-24-generic-pae

LibreOffice 3.5.3.2
Build ID: 350m1(Build:2)

WORKAROUND: openjdk-6 [JRE 1.6.0_24 (Sun Microsystems Inc.)] & found that LO is not that slow & it has not crashed yet.

[szotsaki (szotsaki)]

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.

[Yfjiang (yfjiang)]

Hi szotsaki, would you attach the file caused the problem? I didn't see this issue in my environment.

[Yfjiang (yfjiang)]

Ah, just realized may be the language tool causes the issue, how about the performance after removing languagetool packages? Thanks!

[szotsaki (szotsaki)]

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.

[Björn Michaelsen (bjoern-michaelsen)]

[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:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html

[Björn Michaelsen (bjoern-michaelsen)]

needinfo keyword redundant by needinfo status.

[szotsaki (szotsaki)]

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.

[Daniel Naber (misc2006)]

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())
        SvxLinguConfigUpdate::UpdateAll();

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.

[Daniel Naber (misc2006)]

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.

[Michael Meeks (michael-meeks)]

> 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 ...

[Indian Art (goldfish-aol)]

Here is another error log. Please let me know if I need to upload the other similar error logs relating to this issue. Thanks.

[Indian Art (goldfish-aol)]

Another error log.

However, there seems to be slight improvement with JRE 1.6.0_24 (Sun Microsystems Inc.).

[Matthias Klose (doko)]

crash in libreoffice code

[penalvch (penalvch)]

Indian Art, thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 998778
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

As a potential workaround, if you switch to openjdk-6 via Tools -> Options -> Java does it still crash?

[Michael Meeks (michael-meeks)]

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 1.25.18.4: #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.

[Libreoffice-bugs (libreoffice-bugs)]

Michael Meeks committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8924a7bde1bd5ddb857342b6f8704c250f897078

fdo#35270 - enable caching of grammar checker properties

[Michael Meeks (michael-meeks)]

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).

[Indian Art (goldfish-aol)]

Hi Christopher,
I ran the following command in Terminal:
apport-collect 998778

After giving it an hours access it gave a message that no information was collected.

I have switched to openjdk-6 [JRE 1.6.0_24 (Sun Microsystems Inc.)] & found that LO is not that slow & it has not crashed yet.

However, although it runs much, much faster without Java I need to run JRE for some extensions like OpenOffice.org2GoogleDocs that I use several time a day . Also, there was no problem with JRE/extensions or LO with the previous version of Ubuntu (11.10). I think this version of Ubuntu runs LO faster as long as the Java is not activated.

I am not sure if any of these problems is because of the LO-menubar that I have recently installed & am using.

Thanks.

[Libreoffice-bugs (libreoffice-bugs)]

Michael Meeks committed a patch related to this issue.
It has been pushed to "libreoffice-3-5":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9ecc734f631ce4597782b17b071752b8fa223d49&g=libreoffice-3-5

fdo#35270 - enable caching of grammar checker properties

It will be available in LibreOffice 3.5.4.

[penalvch (penalvch)]

Indian Art, if you uninstall lo-menubar, and switch back to openjdk-7, is the crash reproducible?

[Indian Art (goldfish-aol)]

Christopher, I have uninstalled lo-menubar, and switched back to openjdk-7. I am using/testing it now & will report how it works.

[Indian Art (goldfish-aol)]

Christopher, just openjdk-7 with the lo-menubar uninstalled is still painfully slow. It open & grays out & a 3 line LO document (in .doc format) took more than a minute to load.

Lo with openjdk-7 is almost unusable. However, on disabling the LanguageTool (1.7) extension I am unable to reproduce this bug.

I re-installed the lo-menubar & it works well with openjdk-7. On enabling the LanguageTool (1.7) extension with lo-menubar & openjdk-7 the problem is back.

I think we have the culprit, enabling LanguageTool (1.7) on LO with openjdk-7 causes the undesirable bug.

[Indian Art (goldfish-aol)]

Michael Meeks committed a patch related to this issue that will be available in LibreOffice 3.5.4.

I am eagerly looking forward to LO version 3.5.4. I hope Ubuntu releases this version via Update Manager as soon as it is released.

Re slowness and LanguageTool, also see LibreOffice bug 35270 ( https://bugs.freedesktop.org/show_bug.cgi?id=35270 )

[Björn Michaelsen (bjoern-michaelsen)]

fix commited as 3.5.4 is ready and waiting for SRU/MRE

[Björn Michaelsen (bjoern-michaelsen)]

3.5.7 SRUed to precise.