Bug 1089941 - Very slow loading documents when LibreOffice it not yet open
Very slow loading documents when LibreOffice it not yet open
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: LibreOffice
Current
x86-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: Tomáš Chvátal
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-17 20:25 UTC by Frank Voorburg
Modified: 2018-04-18 20:51 UTC (History)
0 users

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Test document that I used to reproduce the problem (8.13 KB, application/vnd.oasis.opendocument.text)
2018-04-18 08:52 UTC, Frank Voorburg
Details
Output of strace (18.62 KB, text/x-log)
2018-04-18 13:43 UTC, Frank Voorburg
Details
GDB session log (9.71 KB, text/x-log)
2018-04-18 13:45 UTC, Frank Voorburg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Voorburg 2018-04-17 20:25:38 UTC
User-Agent:       Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Build Identifier: 

If LibreOffice is not yet running, it takes too long to open even the simplest of documents. Opening a document with just one line of text takes 20 seconds. On my Debian system with LibreOffice 5, the same document loads in a few seconds. This also happens if you first open LibreOffice Writer and then open a document via File->Open.

If LibreOffice is already running with another opened document, then opening the same test document goes as expected within a few seconds.

When started from the terminal, I do not see any errors or information. While waiting for the document to open, I do not see anything weird on the CPU load. Actually, CPU load stays very low. It seems to wait for something and then continue after something times out.

Some version information:

openSUSE Tumbleweed: version 20180410
LibreOffice: Version 6.0.3.2
             CPU threads: 4
             OS: Linux 4.16
             UI render: default
             VCL: gtk3 
             Locale: en-US (en_US.UTF-8)
             Calc: group
Java: OpenJDK Runtime Environment (IcedTea 3.7.0)
      build 1.8.0_161-b12 suse-2.1-x86_64

I run openSUSE in VMware Workstation Player 14. I tried on it two different PC's with the same result.

I'll happily provide more information. Just instruct me with where to look and what to do to collect whatever info you need.

Reproducible: Always

Steps to Reproduce:
1. Make sure LibreOffice is closed.
2. Open an ODT-file by double-clicking it.

Actual Results:  
Takes > 20 seconds to open the document.

Expected Results:  
That the document opens faster, so within about 5 seconds.

I have the following LibreOffice related applications an packages installed:

LibreOffice Base
LibreOffice Calc
LibreOffice Draw
LibreOffice Impress
LibreOffice Writer
libreoffice
libreoffice-base
libreoffice-branding-upstream
libreoffice-calc
libreoffice-draw
libreoffice-filters-optional
libreoffice-gnome
libreoffice-gtk3
libreoffice-icon-themes
libreoffice-impress
libreoffice-l10n-de
libreoffice-l10n-en
libreoffice-l10n-nl
libreoffice-mailmerge
libreoffice-math
libreoffice-pyuno
libreoffice-share-linker
libreoffice-writer

Output of screenfetch:

 OS: openSUSE 
 Kernel: x86_64 Linux 4.16.0-1-default
 Uptime: 14m
 Packages: 2255
 Shell: bash 4.4.19
 Resolution: 1920x1080
 DE: Cinnamon 3.6.7
 WM: Muffin
 WM Theme: Linux Mint (Arc-Darker)
 GTK Theme: Arc-Darker [GTK2/3]
 Icon Theme: Numix-Circle
 Font: Noto Sans 9
 CPU: Intel Core i5-4670K @ 4x 3.4GHz
 GPU: SVGA3D; build
 RAM: 1444MiB / 7947MiB
Comment 1 Tomáš Chvátal 2018-04-18 07:25:19 UTC
Does it happen also if you just open ie oowriter binary? Or empty documents load up fast?
Comment 2 Frank Voorburg 2018-04-18 08:52:14 UTC
Created attachment 767523 [details]
Test document that I used to reproduce the problem
Comment 3 Frank Voorburg 2018-04-18 08:53:20 UTC
(In reply to Tomáš Chvátal from comment #1)
> Does it happen also if you just open ie oowriter binary? Or empty documents
> load up fast?

The same problem occurs when using the oowriter binary directly. I ran the following from the terminal to produce the problem:
  oowriter /home/<my_username>/Desktop/test.odt

The document is just an empty document with one line of text. I attached it for reference purposes.

Starting LibreOffice writer on its own it not delayed. The problem only occurs when loading a document, if no other document as open yet.

I also found out that saving a document for the first time seems to cause a similar delay. So I start LibreOffice writer and then save the file after adding a little bit of text. If then takes about the same delay to actually save the file. If I then modify the text and save again, it goes fast as expected.
Comment 4 Tomáš Chvátal 2018-04-18 08:58:38 UTC
(In reply to Frank Voorburg from comment #2)
> Created attachment 767523 [details]
> Test document that I used to reproduce the problem

scarabeus@bugaboo: ~ $ time oowriter Downloads/test.odt 

real	0m3,513s
user	0m2,052s
sys	0m0,288s


Seems to work fine here
Comment 5 Tomáš Chvátal 2018-04-18 08:59:12 UTC
(In reply to Frank Voorburg from comment #3)
> (In reply to Tomáš Chvátal from comment #1)
> > Does it happen also if you just open ie oowriter binary? Or empty documents
> > load up fast?
> 
> The same problem occurs when using the oowriter binary directly. I ran the
> following from the terminal to produce the problem:
>   oowriter /home/<my_username>/Desktop/test.odt
> 
> The document is just an empty document with one line of text. I attached it
> for reference purposes.
> 
> Starting LibreOffice writer on its own it not delayed. The problem only
> occurs when loading a document, if no other document as open yet.
> 
> I also found out that saving a document for the first time seems to cause a
> similar delay. So I start LibreOffice writer and then save the file after
> adding a little bit of text. If then takes about the same delay to actually
> save the file. If I then modify the text and save again, it goes fast as
> expected.

You can try to run the package using strace to see if it is looking up something or waiting or something...
Comment 6 Frank Voorburg 2018-04-18 13:41:32 UTC
Here's the output of time measurements on my system:

Timing of just opening oowriter:
    
  voorburg@tumbleweed:~> time oowriter

  real	0m4.982s
  user	0m4.184s
  sys	0m0.562s
    
Timing with opening of the test file:
   
  voorburg@tumbleweed:~> time oowriter ~/Downloads/test.odt 

  real	0m19.993s
  user	0m3.852s
  sys	  0m0.680s
Comment 7 Frank Voorburg 2018-04-18 13:43:02 UTC
Based on your request, I ran strace with the command:
  strace -o oowriter_strace.log oowriter ~/Downloads/test.odt. 

See the attached oowriter_strace.log file.

It freezes on the following line:

  rt_sigaction(SIGINT, {sa_handler=0x5616df255a10, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fb22cd84a70}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fb22cd84a70}, 8) = 0
  wait4(-1,

Then after about 10 seconds oowriter window shows up with the loaded test.odt file and nothing else is outputted by strace.

When I close oowriter, the strace output continues on the line that started with "wait4(-1,":
    
  wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 3141
  rt_sigaction(SIGINT, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fb22cd84a70}, {sa_handler=0x5616df255a10, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fb22cd84a70}, 8) = 0
  ioctl(2, TIOCGWINSZ, {ws_row=66, ws_col=272, ws_xpixel=0, ws_ypixel=0}) = 0
  ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
  getuid()                                = 1000
  geteuid()                               = 1000
  etc.
Comment 8 Frank Voorburg 2018-04-18 13:43:46 UTC
Created attachment 767590 [details]
Output of strace
Comment 9 Frank Voorburg 2018-04-18 13:45:38 UTC
I did a debug session with gdb, which reports a segmentation fault. 

I attached a log of my debug session (gdb_session.log). Perhaps someone can inspect it and find the cause of the problem.
Comment 10 Frank Voorburg 2018-04-18 13:45:58 UTC
Created attachment 767591 [details]
GDB session log
Comment 11 Tomáš Chvátal 2018-04-18 13:47:23 UTC
(In reply to Frank Voorburg from comment #10)
> Created attachment 767591 [details]
> GDB session log

You need to install debuginfo packages for this to be useful, it will replace all those ?? with code pointers, see the gdb recommending those zypper in commands
Comment 12 Frank Voorburg 2018-04-18 13:58:17 UTC
I had all available debug packages installed. The once that are reported missing cannot be found, unfortunately.
Comment 13 Tomáš Chvátal 2018-04-18 14:00:44 UTC
(In reply to Frank Voorburg from comment #12)
> I had all available debug packages installed. The once that are reported
> missing cannot be found, unfortunately.

That is weird, it should work even if you copied out the lines verbatim to those in the gdb? Try at least by hand "zypper in glibc-debuginfo libreoffice-debuginfo"
Comment 14 Frank Voorburg 2018-04-18 16:53:57 UTC
I tried on another system that shows the same symptoms and I was able to install all missing debug packages, except one: "/usr/lib64/libjpeg.so.8". The debug package for this one can also not be found in Yast.

I repeated the same GDB debug session as previously uploaded and the results are the same. Any other ideas on how to get to the bottom of this segmentation fault?
Comment 15 Frank Voorburg 2018-04-18 20:51:28 UTC
After some more testing, I found the cause of the problem and the solution.

As you might have seen in the files I attached previously, I have the hostname of my system set to "tumbleweed". It turns out that this is the cause of the problem. The moment I change the hostname to anything else, the reported problem disappears.

For verification purposes, I created a new Tumbleweed install in VMware Workstation. By default the hostname was "linux-khi1". At this point the problem was not present. Then after changing the hostname to "tumbleweed" using section Network Settings in Yast, the problem appeared. Changing the hostname to something else, made the problem disappear again.

I'll go ahead and update the bug status to resolved.

Tomáš, thanks for your assistance and feedback. It is much appreciated.