Bug 46765 - LO seems freezed for some seconds when a module is started
Summary: LO seems freezed for some seconds when a module is started
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
(earliest affected)
3.5.0 release
Hardware: Other All
: medium normal
Assignee: Not Assigned
Whiteboard: BSA
Depends on:
Reported: 2012-02-29 04:29 UTC by Julien Nabet
Modified: 2013-05-03 00:58 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

lsof diff (2.31 KB, text/plain)
2012-02-29 04:33 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2012-02-29 04:29:03 UTC
Problem description: 
Once any module of LO is launched (at least, Writer or Calc), when you type something, the module freezes for some seconds.
Then the character typed is displayed and everything is ok.

It's on 3.5 branch (so not exactly 3.5.0).

For more details, see thread thread http://nabble.documentfoundation.org/Trying-to-understand-why-LO-seems-freezed-for-some-seconds-when-a-module-is-started-td3735600.html
It seems this bug is also present on Mac.

Steps to reproduce:
1. Launch Writer or Calc
2. Type 1 character

Current behavior:
Freezing during some seconds

Expected behavior:
No freeze

Platform (if different from the browser): 
Debian pc 64-x86
Browser: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Comment 1 Julien Nabet 2012-02-29 04:33:56 UTC
Created attachment 57801 [details]
lsof diff

I attached the difference between the result of these commands :
lsof -p `pidof soffice.bin` > before.txt (just after the launch of a LO module)
lsof -p `pidof soffice.bin` > after.txt (just after the freeze)
Comment 2 Julien Nabet 2012-02-29 04:37:47 UTC
Since I compile 3.5 branch from sources and following some advice from the thread quoted in my previous message, I had disabled lightproof, here's the autogen.lastrun used :


(I use Boost 1.48 so it's compiled with 1.48 default version instead of 1.44)

other info :
gcc (Debian 4.6.2-12)

java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b24~pre2-1)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode) 

Python 2.7
Comment 3 Michael Meeks 2012-02-29 06:07:42 UTC
Can you confirm whether you see this with the lightproof extension removed / disabled as well ? if it's hard to attach gdb and get some backtraces during the hang, can you do:

strace -f -s 256 -ttt -o /tmp/log -p `pidof soffice.bin`

just before triggering the slowness run the above, ctrl-c killing it after the slowness is ended and attach the log (gzipped) ? :-)

many thanks.
Comment 4 Julien Nabet 2012-02-29 14:47:15 UTC
Michael: strace bzip2 from master is more than 3MB, I can't attach it :-(

I reproduced the pb with master too (but I didn't run "make clean" after having removed lightproof).

Compiling 3.5 right now (I had done a make clean to be sure there's nothing left about lightproof)
Comment 5 Michael Meeks 2012-02-29 21:56:11 UTC
> Michael: strace bzip2 from master is more than 3MB, I can't attach it :-(

Wow !? and you are not stracing from the beginning - but stracing just the piece that is slow ? if so, that's rather amazing.

Possibly removing the '-s 256' would help shrink the log output :-) then again - you can always mail me the trace if you like !

Comment 6 tommy27 2012-03-01 03:40:38 UTC
this 2-3 seconds freeze at module start is present in LibO 3.5.0 but not in LibO 3.4.5.

this freeze is unrelated to autocorrection (having an empty autocorrect database or a huge one doesn't have any influence with this).

another different freeze moment exists, which instead depends on the number of autocorrect entries. see Bug 46805
Comment 7 Julien Nabet 2012-03-01 14:47:48 UTC
Compiled master from scratch, the freeze is 1 or 2 seconds only now !
I'm compiling 3.5 branch right now.

I'll give new strace later, this time I think it won't be too big to attach to this bug :-)
Comment 8 tommy27 2012-03-01 22:23:22 UTC
As I told before there were 2 consecutive freezes, probably due to different issues.

the 2nd freeze which was longer ( Bug 46805 ) was related to autocorrect and fixed by Dezsi patch. It will be in 3.5.1 I think

the shorter 1st freeze ( Bug 46765 ) is still there and is the one you are still experiencing in master.
Comment 9 Michael Meeks 2012-03-02 02:22:16 UTC
Thanks Julien - so your strace shows a huge amount of Java-ness happening :)

If we grep the strace log for 'open' we can see roughly what is going on:

30050 1330554064.682136 open("/home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/../program/libspelllo.so", O_RDONLY) = 78
30050 1330554064.716435 open("/proc/self/maps", O_RDONLY) = 78
30050 1330554064.717226 read(78, "05 154162                     /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libjava.so\n7fae9fc8c000-7fae9fe8b000 ---p 0002d000 08:05 154162                     /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libjava.so\n7fae9fe8b000-7fae9fe8f000 rw-p 0002"..., 1024) = 1024
30050 1330554064.717276 read(78, "jvm.so\n7faea0ba0000-7faea0c3b000 rw-p 00902000 08:05 270149                     /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/server/libjvm.so\n7faea0c3b000-7faea0c64000 rw-p 00000000 00:00 0 \n7faea0d35000-7faea0d67000 rw-p 00000000 00:00 0 \n7faea0d67000-"..., 1024) = 1024
30050 1330554064.717437 read(78, "ridl.jar\n7faea0e97000-7faea0e9a000 r--s 0007d000 08:05 140243                     /usr/lib/jvm/java-6-openjdk-common/jre/lib/jsse.jar\n7faea0e9a000-7faea0e9b000 r--s 00001000 08:07 532036                     /home/julien/compile-libreoffice/libo/solver/unxl"..., 1024) = 1024
30050 1330554064.721801 open("/home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/../share/extensions/LanguageTool/LanguageTool.uno.jar", O_RDONLY) = 78
30050 1330554064.750712 open("/proc/self/maps", O_RDONLY) = 78

ie. you have LanguageTool.uno.jar installed - and this is your problem :-)

30050 1330554067.076199 open("/home/julien/compile-libreoffice/libo/solver/unxlngx6/installation/opt/program/../program/pythonloader.uno.so", O_RDONLY) = 80

After spending from 64.7 seconds to 67.08 seconds - ie. 2+ seconds initializing java, we move onto dealing with python.

30050 1330554067.226163 open("/usr/lib/python2.7/string.pyc", O_RDONLY) = 82

The python init seems to take under 0.2 of a second.

And then we start doing crazy Java stuff again - endless parsing of /proc/self/maps as we attach / detach that stuff.

So - this is a known bug; bootstrapping Java & LanguageTool takes ~nearly forever :-) and there is really not much we can do about that (sadly).
Comment 10 Daniel Naber 2012-05-10 08:26:31 UTC
Just for the record, the long freeze Michael ist talking about is Bug 35270 which can hopefully be fixed now it seems.