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
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)
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 : --with-system-boost --enable-symbols --enable-ext-barcode --enable-ext-diagram --enable-ext-google-docs --enable-ext-hunart --enable-ext-languagetool --enable-ext-nlpsolver --enable-ext-ct2n --enable-ext-numbertext --enable-ext-oooblogger --enable-ext-pdfimport --enable-ext-postgresql-sdbc --enable-ext-presenter-console --enable-ext-presenter-minimizer --enable-ext-report-builder --enable-ext-scripting-beanshell --enable-ext-scripting-javascript --enable-ext-typo --enable-ext-validator --enable-ext-watch-window --enable-ext-wiki-publisher --enable-dbus --enable-graphite --enable-evolution2 --enable-werror --enable-debug --enable-dbgutil --enable-crashdump --enable-kde4 --enable-dependency-tracking --enable-online-update (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
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.
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)
> 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 ! Thanks.
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
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 :-)
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.
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).
Just for the record, the long freeze Michael ist talking about is Bug 35270 which can hopefully be fixed now it seems.