In both RC1 and RC2 the program takes a long time (>30s) to start (cold or hot). I run a Debian Testing in a X86_64 envirorment, speed is normal in other aplications and even in OpenOffice 3.2 packaged with distro. Have already tried to uninstall Ooo 3.2 to see if it some kind of conflict, but bug remains. Have tried to run it with and without the pt-br language pack (by the way both times the splash screen shows "BrOffice" so locale is being set automatically at some point). Hope to get a better start time with the 3.3 final release :) Rogerio
Can you please provide us with a strace? http://wiki.documentfoundation.org/BugReport#How_to_get_strace_log_.28on_Linux.29 Thank you!
Created attachment 41493 [details] Strace for LibreOffice start, exit as soon as I see the program window Here is the strace of a cold start. Took about 30 seconds to the splash screen, which then loaded the program very fast. Rogerio
Partly at least could be DNS problems? At least one long delay in the strace output seem to come after a DNS lookup. See after 19:30:47.221358.
(In reply to comment #3) > Partly at least could be DNS problems? At least one long delay in the strace > output seem to come after a DNS lookup. See after 19:30:47.221358. Why would there be a call to a DNS? Hwo to fix this ? Rogerio
(In reply to comment #4) > (In reply to comment #3) > > Partly at least could be DNS problems? At least one long delay in the strace > > output seem to come after a DNS lookup. See after 19:30:47.221358. > > Why would there be a call to a DNS? > Hwo to fix this ? > Rogerio Ok an update: Have just reinstalled a Debian Testing system with only gnome-core / wicd / iceweasel / And tried a install with the X86_64 packages. The problem persists Will send another strace Rogerio
Created attachment 41713 [details] Agan Strace My mistake, I said it took >30s, when it actually is 45sec to splash-screen Ok so I could narrow down the delay to the following: 3285 19:30:47.321175 poll([{fd=3, events=POLLIN}], 1, 4900) = 0 (Timeout) 3285 19:30:52.226272 gettimeofday({1293571852, 226326}, NULL) = 0 3285 19:30:52.226384 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3, revents=POLLOUT}]) 3285 19:30:52.226476 sendto(3, "\342\270\1\0\0\1\0\0\0\0\0\0\4novo\6(none)\0\0\1\0\1", 29, MSG_NOSIGNAL, NULL, 0) = 29 3285 19:30:52.226596 poll([{fd=3, events=POLLIN}], 1, 5000) = 1 ([{fd=3, revents=POLLIN}]) 3285 19:30:52.330801 ioctl(3, FIONREAD, [29]) = 0 3285 19:30:52.330908 recvfrom(3, "\0\0\201\2\0\1\0\0\0\0\0\0\4novo\6(none)\0\0\1\0\1", 1024, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("192.168.2.1")}, [16]) = 29 3285 19:30:52.331032 gettimeofday({1293571852, 331059}, NULL) = 0 3285 19:30:52.331113 poll([{fd=3, events=POLLIN}], 1, 4895 <unfinished ...> 3286 19:30:57.052734 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) 3286 19:30:57.052873 gettimeofday({1293571857, 52901}, NULL) = 0 With both calls of "poll" the gettimeofday delays 5 seconds each ... giving in just this passage a 10s delay ... Another 5secs 3285 19:31:02.331916 poll([{fd=3, events=POLLIN}], 1, 4895 <unfinished ...> 3286 19:31:07.053026 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out) 3286 19:31:07.053147 gettimeofday({1293571867, 53176}, NULL) = 0 and then another 5s of try to resolve the same functions: Starting at this last block and going ALL THE WAY DOWN to the end of Strace 3285 19:31:10.439353 close(29) = 0 3285 19:31:10.439621 open("/home/rogerio/.libreoffice/3/user/psprint", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 29 3285 19:31:10.439721 close(29) = 0 3285 19:31:10.439811 access("/home/rogerio/.libreoffice/3/user/psprint/psprint.conf", F_OK) = -1 ENOENT (No such file or directory) 3285 19:31:10.439922 open("/home/rogerio/.libreoffice/3/user/psprint/psprint.conf", O_RDONLY) = -1 ENOENT (No such file or directory) 3285 19:31:10.441532 gettimeofday({1293571870, 441573}, NULL) = 0 Rogerio
True also for the official 3.3.0 release. Rogerio
woah - that is odd. We should not be doing a reverse DNS lookup here - though I hear of another report of somesuch strange slowness. Rogerio - since you have a brilliant test case can you: cd /prefix/program gdb ./soffice.bin run <wait until ten seconds into the delay> <ctrl-c> thread apply all backtrace and attach the log here ? There should be no need for DNS at startup, so this is just some silly regression bug I think. With a stack trace we can tackle this quite easily I think. [ It would be even more ideal if you could install some debuginfo package to get symbols for the trace, but that's not completely necessary ]. Thanks !
Here goes the log generated by gdb: (gdb) thread apply all backtrace Thread 2 (Thread 0x7fffeec40700 (LWP 15450)): #0 0x00007ffff63174d9 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007ffff7a3f630 in ?? () from /opt/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3 #2 0x00007ffff63128ba in start_thread () from /lib/libpthread.so.0 #3 0x00007ffff67fb02d in clone () from /lib/libc.so.6 #4 0x0000000000000000 in ?? () Thread 1 (Thread 0x7ffff7fd1700 (LWP 15447)): #0 0x00007ffff67f0113 in poll () from /lib/libc.so.6 #1 0x00007fffe99aa8ce in ?? () from /lib/libresolv.so.2 #2 0x00007fffe99a8a75 in __libc_res_nquery () from /lib/libresolv.so.2 #3 0x00007fffe99a9031 in ?? () from /lib/libresolv.so.2 #4 0x00007fffe99a92b1 in __libc_res_nsearch () from /lib/libresolv.so.2 #5 0x00007fffe8f51fb8 in _nss_dns_gethostbyname3_r () from /lib/libnss_dns.so.2 #6 0x00007fffe8f521ee in _nss_dns_gethostbyname_r () from /lib/libnss_dns.so.2 #7 0x00007ffff6812103 in gethostbyname_r () from /lib/libc.so.6 #8 0x00007ffff7a19704 in ?? () from /opt/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3 #9 0x00007ffff7a199ab in ?? () from /opt/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3 #10 0x00007ffff7a19c9a in ?? () from /opt/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3 #11 0x00007ffff7a19e34 in ?? () from /opt/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3 #12 0x00007ffff7a19e8a in osl_getLocalHostname () from /opt/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3 #13 0x00007fffec2fe1f5 in X11SalData::X11SalData() () from /opt/libreoffice/basis3.3/program/libvclplug_genlx.so #14 0x00007fffeddf0e9f in create_SalInstance () from /opt/libreoffice/basis3.3/program/libvclplug_gtklx.so #15 0x00007ffff3398669 in ?? () from /opt/libreoffice/program/../basis-link/program/libvcllx.so #16 0x00007ffff339895a in ?? () from /opt/libreoffice/program/../basis-link/program/libvcllx.so #17 0x00007ffff3398b97 in ?? () from /opt/libreoffice/program/../basis-link/program/libvcllx.so #18 0x00007ffff30f7b37 in InitVCL(com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const&) () from /opt/libreoffice/program/../basis-link/program/libvcllx.so #19 0x00007ffff30f88aa in ?? () from /opt/libreoffice/program/../basis-link/program/libvcllx.so #20 0x00007ffff30f8a95 in SVMain() () from /opt/libreoffice/program/../basis-link/program/libvcllx.so #21 0x00007ffff77bf53c in soffice_main () from /opt/libreoffice/program/../basis-link/program/libsofficeapp.so #22 0x0000000000400fdb in main () (gdb)
Created attachment 43627 [details] The gdb log as asked by M.Meeks in his post #8
Created attachment 43649 [details] fix the issue ... This was introduced while fixing a KDE specific bug: http://www.openoffice.org/issues/show_bug.cgi?id=47904 Under gtk+ we don't use this setting anyway, so we can avoid doing the reverse lookup at all. Trivial patch attached seeks review :-) I've pushed it to master.
Cherry-picked into libreoffice-3-3, thank you!
.
Remove infoprovider from closed and resolved bugs.
RESOLVED, FIXED or CLOSED bugs cant be KEYWORD NEEDINFO.