Created attachment 57471 [details] This is a Writer window with a "top" command output. Problem description: Current behavior: soffice.bin loads the CPU on 90-100%, even when I do nothing. This problem is rather annoying, and it can be watched both in Linux Ubuntu (Xubuntu 11.10, if to be more exact) and Windows 7. Expected behavior: Platform (if different from the browser): Xubuntu 11.10. I have also registered this problem on Win7. Browser: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Thanks for bugreport Please, verify if in last version of LibreOffice still reproducible
I think, that I have the same problem. I think, that this problem is in LibO 3.5.x, not only in writer, but also in calc and is RAPIDLY growing with the size of document (in writer) and complexity of tables (calc). Only a small effect has the smoothing of fonts. I work with a big document (now approx. 900 pages A5 without any extra formatting - translating document: one paragraph style for one language and second paragraph style for the second language) and with complex tables. I use OpenSUSE 11.4 (some older dual Intel, 4GB RAM, 64bit) and OpenSUSE 12.1 (AMD APU A6, 8GB RAM, 64bit). In LO 3.4.5 I have not any problem to work with them (it is problem to find soffice.bin in top and typical value is around 3% of CPU load). In LO 3.5.1 and (the second experiment) 3.5.3 it is very troublesome: - loading the document (~900 pages, se above) - CPU load is approuching nearly 200% (~180%) - loaded (the above) document without working - ~30-60% CPU load - writing (into the above) document - ~60-100% CPU load Probably similar situation is in calc (I did not follow CPU load). Interesting is, that mouse operations looks better, than keyboard operations, but, for instance, double click on some word (marking word) is significantly delayed. Navigation with keyboard is very slowly (shift+arrow, PgDown, Ctrl-PgDown, Ctrl-End etc.) and I must wait for a moment, when system react! It looks like not buffer is in action!
Thanks for additional testing. Please try this and tell output of it: export OOO_DISABLE_RECOVERY=1 valgrind --tool=callgrind --simulate-cache=yes --dump-instr=yes ./soffice.bin -writer --splash-pipe=0
Wow - this is a nasty; marking confirmed with two users. As sasha says - a callgrind trace might help - we'd need debuginfo packages installing though for it to be useful. Also - we fixed a number of similar / related issues around interactive word-count that are specific to certain document types. Caolan fixed a number of these in more recent versions. Is there any chance you can test the 3.6 beta1 for example, or a much more recent 3.5.4 ? Thanks !
Another variant, bug this time with very short text: Bug 47636
Sorry, I do not know valgrind, so I create some experiments... See http://dl.dropbox.com/u/58425784/lo-valgrind.tar.bz2 File soffice-valgrind is from Intel, 4GB RAM, OpenSUSE 11.4, the others are from AMD, 8GB RAM, OpenSUSE 12.1. From stable repository Libreoffice (3.5.3).
Its hard to tell from a "its slow" report if its a duplicate of some of the fixed things, e.g. http://cgit.freedesktop.org/libreoffice/core/commit/?id=4bc06051d1bf484a6f98186f0a2d168b3d98b9cc and http://cgit.freedesktop.org/libreoffice/core/commit/?id=8ceb098374284d4ab78a6e6e649b0674dcae40d4) or not. It'd be great if someone who can reproduce the problems can try with 3.6 beta to see if they still exist there ? The original report shows a near-100% cpu load on an apparently empty document. Was that just launching writer and doing nothing. Or was is launching writer, doing something and closing documents until only an empty document remains ?
needinfo - any chance of re-trying with a LibreOffice 3.6 snapshot build :-)
Created attachment 63588 [details] valgrind on dualcore intel, 4 GB RAM, OpenSUSE 11.4 I installed LO 3.6 beta from repository http://download.opensuse.org/repositories/home:/pmladek:/LibreOffice:/3.6 into OpenSUSE 11.4. My first knowledges: It is much more better, then 3.5 - working with nearly 1000 pages document (with exception of starting of editing - see later) is relatively OK. But some navigation and editing operation are 'rather' delayed - not more than ~0,25s. It is much better, than with 3.5.3. Valgrind - see file Delay after opening document: After opening a big document, LO some time (less then ~10 sec.) reacts to keyboard corectly. But after it there is a delay about ~10-15 sec. After delay it shows the whole inserted text.
CPU load occasionally increases to 96% when running libreoffice in headless mode for doc conversions. It chokes my server until I manually kill the soffice.bin process. Here is the command I'm running: libreoffice3.6 --headless -convert-to pdf I use this command in a semi-continuous daemon service converting .docs to .pdf, among other things. It doesn't seem to happen as a result of a given input-- just seems to go off every 6 to 8 hours or so. I will post more information as it comes to light.
Joe - that sounds interesting ! :-) sounds like a leaked idle handler / timer. As/when that happens can you attach gdb and press ctrl-c and get a backtrace for me ? getting a few of those (outside of the polling loop) would be really useful. Failing that, running something like oprofile might show us where the time is spent; and/or a simpler way to confirm my hypothesis above is to run a quick strace -ttt -s 256 -f -p `pidof soffice.bin` -o /tmp/slog for a while - and gzip / attach the slog. Thanks ! :-)
Hi Michael! Thanks very much for giving attention to this. The event just recurred today. Here's the strace: [root@blargh ~]# tail -F /tmp/slog 27948 1353360145.327741 futex(0x7f0106d90c60, FUTEX_WAKE_PRIVATE, 1) = 0 27948 1353360145.327820 futex(0x7f0106d90ecc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5647, {1353360155, 327666000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) 27948 1353360155.327888 gettimeofday({1353360155, 327942}, NULL) = 0 27948 1353360155.328019 futex(0x7f0106d90c60, FUTEX_WAKE_PRIVATE, 1) = 0 27948 1353360155.328099 futex(0x7f0106d90ecc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5649, {1353360165, 327942000}, ffffffff <unfinished ...> 27947 1353360163.632323 mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f00dc2a0000 27948 1353360165.337391 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) 27948 1353360165.337504 gettimeofday({1353360165, 337525}, NULL) = 0 27948 1353360165.337601 futex(0x7f0106d90c60, FUTEX_WAKE_PRIVATE, 1) = 0 27948 1353360165.337682 futex(0x7f0106d90ecc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5651, {1353360175, 337525000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) 27948 1353360175.337821 gettimeofday({1353360175, 337846}, NULL) = 0 27948 1353360175.337923 futex(0x7f0106d90c60, FUTEX_WAKE_PRIVATE, 1) = 0 27948 1353360175.338010 futex(0x7f0106d90ecc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5653, {1353360185, 337846000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) 27948 1353360185.338164 gettimeofday({1353360185, 338189}, NULL) = 0 27948 1353360185.338268 futex(0x7f0106d90c60, FUTEX_WAKE_PRIVATE, 1) = 0 27948 1353360185.338355 futex(0x7f0106d90ecc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5655, {1353360195, 338189000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) 27948 1353360195.338514 gettimeofday({1353360195, 338559}, NULL) = 0 27948 1353360195.338661 futex(0x7f0106d90c60, FUTEX_WAKE_PRIVATE, 1) = 0 27948 1353360195.338971 futex(0x7f0106d90ecc, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 5657, {1353360205, 338559000}, ffffffff^C Unfortunately I don't have a bigger excerpt for you because my server imploded soon thereafter. :-D Let me know if you need more from me. Thanks again!
What an odd strace - it looks like a timed wait on a mutex that is not unlocked ever - with some busy loop waking noticing it's not done and going back to sleep: sucky indeed. Prolly associated with a deadlock. As such this -should- be quite easy to find. As/when it happens again - can you attach gdb and do: thread apply all backtrace with a strong preference for having symbols installed, and attach the full backtrace there ? :-) Thanks !
I'm seeing this under 3.6.2 on Ubuntu 12.10 too, with the same FUTEX messages Joe was getting (that's how I stumbled across this bug). Its been happening several times a day with a particular spreadsheet I'm editing, which is stored in Excel format. It seems to be happening in relation to auto-save from the looks of things, triggering a save myself doesn't cause any problems. The following is the output from the requested gdb output: (gdb) thread apply all backtrace Thread 7 (Thread 0x7f84991c2700 (LWP 16071)): #0 0x00007f84a49890fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f84a59ffea9 in ?? () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_sal.so.3 #2 0x00007f84a4984e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #3 0x00007f84a4c8dcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x0000000000000000 in ?? () Thread 6 (Thread 0x7f8492186700 (LWP 16074)): #0 0x00007f84a4c8ea6d in accept () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f84a59f4140 in osl_acceptPipe () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_sal.so.3 #2 0x00007f84a57b453a in ?? () from /usr/lib/libreoffice/program/libsofficeapp.so #3 0x00007f84a3891d56 in salhelper::Thread::run() () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_salhelpergcc3.so.3 #4 0x00007f84a3891fca in ?? () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_salhelpergcc3.so.3 #5 0x00007f84a59f9bb7 in ?? () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_sal.so.3 #6 0x00007f84a4984e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #7 0x00007f84a4c8dcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #8 0x0000000000000000 in ?? () Thread 5 (Thread 0x7f848a949700 (LWP 16075)): #0 0x00007f84a4c82303 in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f849dc64d84 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x00007f849dc651e2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x00007f849e22f4a6 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 #4 0x00007f849dc88645 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007f84a4984e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007f84a4c8dcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x0000000000000000 in ?? () Thread 4 (Thread 0x7f847e65d700 (LWP 16076)): #0 0x00007f84a4c82303 in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f8496d186c5 in ?? () from /usr/lib/libreoffice/program/libvclplug_genlo.so #2 0x00007f8496d188a6 in ?? () from /usr/lib/libreoffice/program/libvclplug_genlo.so #3 0x00007f84a59f9bb7 in ?? () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_sal.so.3 #4 0x00007f84a4984e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x00007f84a4c8dcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #6 0x0000000000000000 in ?? () Thread 3 (Thread 0x7f8492987700 (LWP 16084)): #0 0x00007f84a4c82303 in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f8496cfea58 in ?? () from /usr/lib/libreoffice/program/libvclplug_genlo.so #2 0x00007f84a59f9bb7 in ?? () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_sal.so.3 #3 0x00007f84a4984e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x00007f84a4c8dcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #5 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f8477fff700 (LWP 28759)): #0 0x00007f84a49890fe in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x00007f84a5a197e0 in osl_waitCondition () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_sal.so.3 #2 0x00007f849110103c in ?? () from /usr/lib/libreoffice/program/../program/libfwklo.so #3 0x00007f84910e95da in ?? () from /usr/lib/libreoffice/program/../program/libfwklo.so #4 0x00007f84a59f9bb7 in ?? () from /usr/lib/libreoffice/program/../ure-link/lib/libuno_sal.so.3 #5 0x00007f84a4984e9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x00007f84a4c8dcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 #7 0x0000000000000000 in ?? () Thread 1 (Thread 0x7f84a5e23940 (LWP 16070)): #0 0x00007f848bc88cf4 in ?? () from /usr/lib/libreoffice/program/../program/i18npool.uno.so #1 0x00007f848860efc3 in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #2 0x00007f84886079da in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #3 0x00007f8488608f93 in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #4 0x00007f8488616d04 in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #5 0x00007f848861745c in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #6 0x00007f848861b204 in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #7 0x00007f84885d778c in EditEngine::SetUpdateMode(unsigned char) () from /usr/lib/libreoffice/program/../program/libeditenglo.so #8 0x00007f8476e33b27 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #9 0x00007f84886c34e9 in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #10 0x00007f84886c35c2 in ?? () from /usr/lib/libreoffice/program/../program/libeditenglo.so #11 0x00007f847f2cb68f in XMLTextParagraphExport::exportParagraph(com::sun::star::uno::Reference<com::sun::star::text::XTextContent> const&, unsigned char, unsigned char, unsigned char, MultiPropertySetHelper&) () from /usr/lib/libreoffice/program/../program/libxolo.so #12 0x00007f847f2c85c2 in XMLTextParagraphExport::exportTextContentEnumeration(com::sun::star::uno::Reference<com::sun::star::container::XEnumeration> const&, unsigned char, com::sun::star::uno::Reference<com::sun::star::text::XTextSection> const&, unsigned char, unsigned char, com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const*, unsigned char) () from /usr/lib/libreoffice/program/../program/libxolo.so #13 0x00007f847f2ccba6 in XMLTextParagraphExport::exportText(com::sun::star::uno::Reference<com::sun::star::text::XText> const&, unsigned char, unsigned char, unsigned char) () from /usr/lib/libreoffice/program/../program/libxolo.so #14 0x00007f8476b5cf1e in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #15 0x00007f8476b5de3b in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #16 0x00007f8476b5ee81 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #17 0x00007f847f0d3573 in ?? () from /usr/lib/libreoffice/program/../program/libxolo.so #18 0x00007f847f0d696a in SvXMLExport::exportDoc(xmloff::token::XMLTokenEnum) () from /usr/lib/libreoffice/program/../program/libxolo.so #19 0x00007f8476b54837 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #20 0x00007f847f0d260b in SvXMLExport::filter(com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /usr/lib/libreoffice/program/../program/libxolo.so #21 0x00007f8476b49dd7 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #22 0x00007f8476b92ed4 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #23 0x00007f8476b94a35 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #24 0x00007f8476c54a38 in ?? () from /usr/lib/libreoffice/program/../program/libsclo.so #25 0x00007f8476c54c67 in ScDocShell::SaveAs(SfxMedium&) () from /usr/lib/libreoffice/program/../program/libsclo.so #26 0x00007f84a34f4fa3 in SfxObjectShell::SaveAsOwnFormat(SfxMedium&) () from /usr/lib/libreoffice/program/libsfxlo.so #27 0x00007f84a34f8dfc in ?? () from /usr/lib/libreoffice/program/libsfxlo.so #28 0x00007f84a34fa24a in ?? () from /usr/lib/libreoffice/program/libsfxlo.so #29 0x00007f84a34fc3bd in ?? () from /usr/lib/libreoffice/program/libsfxlo.so #30 0x00007f84a34ea179 in ?? () from /usr/lib/libreoffice/program/libsfxlo.so #31 0x00007f84a354204c in ?? () from /usr/lib/libreoffice/program/libsfxlo.so #32 0x00007f84a354341a in SfxBaseModel::storeToRecoveryFile(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () from /usr/lib/libreoffice/program/libsfxlo.so #33 0x00007f8491169dec in ?? () from /usr/lib/libreoffice/program/../program/libfwklo.so #34 0x00007f849116b0ae in ?? () from /usr/lib/libreoffice/program/../program/libfwklo.so #35 0x00007f849116baa5 in ?? () from /usr/lib/libreoffice/program/../program/libfwklo.so #36 0x00007f84a14b0866 in Timer::ImplTimerCallbackProc() () from /usr/lib/libreoffice/program/libvcllo.so #37 0x00007f84987572a3 in ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so #38 0x00007f849dc64ab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #39 0x00007f849dc64de8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #40 0x00007f849dc64ea4 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #41 0x00007f8498759441 in ?? () from /usr/lib/libreoffice/program/libvclplug_gtklo.so #42 0x00007f84a14a75e4 in Application::Yield(bool) () from /usr/lib/libreoffice/program/libvcllo.so #43 0x00007f84a14a7687 in Application::Execute() () from /usr/lib/libreoffice/program/libvcllo.so #44 0x00007f84a578c4d3 in ?? () from /usr/lib/libreoffice/program/libsofficeapp.so #45 0x00007f84a14afa79 in ?? () from /usr/lib/libreoffice/program/libvcllo.so #46 0x00007f84a14afb05 in SVMain() () from /usr/lib/libreoffice/program/libvcllo.so #47 0x00007f84a57b8456 in soffice_main () from /usr/lib/libreoffice/program/libsofficeapp.so #48 0x00000000004006bb in ?? () #49 0x00007f84a4bbb76d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #50 0x00000000004006f1 in ?? () #51 0x00007fff0c377818 in ?? () #52 0x000000000000001c in ?? () #53 0x0000000000000002 in ?? () #54 0x00007fff0c37997a in ?? () #55 0x00007fff0c3799a3 in ?? () #56 0x0000000000000000 in ?? ()
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
@Joe Hagerty are you still seeing this issue with current 4.0.5 or 4.1.2 release?
(In reply to comment #16) > @Joe Hagerty > are you still seeing this issue with current 4.0.5 or 4.1.2 release? I'm seeing the same strace as in comment #12 but with ooimpress version libreoffice-core/impress-4.2.1.1-1.fc20.x86_64 Not all slide decks trigger it. strace: [pid 16718] 1394031255.899177 futex(0x7f387c000910, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 16718] 1394031255.899212 futex(0x7f387c0008e4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 201, {1394031255, 924207000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) [pid 16718] 1394031255.924292 futex(0x7f387c000910, FUTEX_WAKE_PRIVATE, 1) = 0 [pid 16718] 1394031255.924318 futex(0x7f387c0008e4, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 203, {1394031255, 949313000}, ffffffff) = -1 ETIMEDOUT (Connection timed out) perf report looks like this: Samples: 490K of event 'cycles', Event count (approx.): 313178524525 + 14.25% soffice.bin libeditenglo.so [.] 0x00000000000c6b34 + 5.13% soffice.bin libvcllo.so [.] 0x0000000000443c0d + 3.88% soffice.bin libc-2.18.so [.] _int_free + 3.47% soffice.bin libsvllo.so [.] SfxItemSet::GetItemState(unsigned short, unsigned ch + 3.26% soffice.bin libharfbuzz.so.0.924.0 [.] 0x000000000002216f + 3.10% soffice.bin libc-2.18.so [.] _int_malloc + 2.83% soffice.bin libc-2.18.so [.] malloc + 2.43% soffice.bin libuno_sal.so.3 [.] rtl_uString_release + 2.19% soffice.bin libsvllo.so [.] SfxItemPool::Put(SfxPoolItem const&, unsigned short) + 1.98% soffice.bin libsvllo.so [.] SfxItemSet::Get(unsigned short, unsigned char) const + 1.80% soffice.bin libsvxcorelo.so [.] 0x00000000003246d9 + 1.18% soffice.bin libuno_sal.so.3 [.] rtl_uString_assign + 1.16% soffice.bin libpthread-2.18.so [.] pthread_mutex_lock + 1.16% soffice.bin libuno_sal.so.3 [.] rtl_uString_acquire + 1.09% soffice.bin libpthread-2.18.so [.] pthread_mutex_unlock + 1.07% soffice.bin libstdc++.so.6.0.19 [.] operator new(unsigned long) + 1.05% soffice.bin libsvllo.so [.] SfxItemPool::GetDefaultItem(unsigned short) const + 0.88% soffice.bin libsvllo.so [.] SfxItemPool::Remove(SfxPoolItem const&) + 0.82% soffice.bin libsvllo.so [.] SfxWhichIter::NextWhich() + 0.68% soffice.bin libsvllo.so [.] SfxItemSet::~SfxItemSet() + 0.68% soffice.bin libc-2.18.so [.] free + 0.63% soffice.bin libsvllo.so [.] SfxItemPool::IsInRange(unsigned short) const + 0.62% soffice.bin libvcllo.so [.] ServerFont::GetRawGlyphIndex(unsigned int, unsigned + 0.59% soffice.bin libuno_sal.so.3 [.] 0x0000000000032156 + 0.58% soffice.bin libi18nlangtag.so [.] LanguageTag::LanguageTag(LanguageTag const&) + 0.57% soffice.bin libvcllo.so [.] ServerFont::GetGlyphData(int) mpstat shows a single core pegged 100% in userspace.
It'd really help to have a stack-trace with debuginfo installed - it's quite tantelizing to see things that might help - but not have enough info to do anything =)
Created attachment 95170 [details] perf record with symbols
Thanks Michael, I installed the debuginfo package and did another perf record. The plaintext output of perf report is attached to this bz. It actually takes approx 2m30s to open this deck...others open instantly. Please let me know what other data I can collect.
I downgraded to libreoffice-core/impress-4.1.3.2-9.fc20.x86_64 and the problematic presentation loads normally again (few seconds).
Comments #17-21 refer to a slow load of a odp which is addressed in bug 75622 (i.e. if I revert that fix then Jeremy's odp loads incredibly slow and with that fix restored its ok again). Which means the original problem of #1-#16 is not addressed by that, seeing as that specific to .odp loading. But given that its been 12 months since the last comment on section 1 and its not a confusion of multiple issues I reckon that this particular bug is a dead loss at this stage.