I've been hit by this for quite some time now - I cannot recall if this was introduced with LO4 or if this has been the case in earlier releases as well. The situation is this: On my Mac, when I have a network drive mounted through a slow VPN connection, LO Writer (but possibly others as well) hangs for an amount of time depending on the network speed upon simple user interactions, like adding a line break into a document. This can be reproduced even if that document being edited is not saved yet - so basically there is nothing that should cause LO to access the network drive. Nevertheless it does - the problem just disappears when the network drive is unmounted. Looking at some I/O-Profiling I did I can see that LO attempts to access a huge number of files on the network drive that I had open in the past. Seeing all those reads it is quite obvious that this will be slow. The question is - what does it try to do on the network drive? Neither of those documents is opened currently. And why does it do this upon simple user interactions. I could see this activity on my Mac with the Instruments/File Activity tool. Unfortunately the trace contains some confidential information, so I cannot share it. But I believe it would be reproducible easily.
Would it be possible you give the complete url of some files so it could shed some lights on the problem? Indeed, I suppose that not all the files are confidential, above all just their file name!
Of course, for example /Volume/work/Rechnungen/3K-2014-065.odt This is a file I had open last week. /Volumes/work/Angebote/time-and-material.odt Another file I had open some time this week. /Volumes/work is the mount point of the network share. If needed I can provide more file names,I just cannot attach the full dump.
In this tool (Instruments/Files on osx) I just see file/dir operations. And all I see there is paths, no URLs. If you tell me how to capture what you are looking for I am more than happy to provide this.
If you clear your recent document list, does it work faster?
Clearing the history resolves the problem until a document from that network share is opened. Then I again see a lag when doing simple operations in another document that is not yet saved. Though not nearly as bad as it was initially when the recent documents list was full of documents from that share (which happens to be the main share I store documents on). So it seems that it is actually the recent document list that is causing the problem.
In Windows, I don't detect any file activity on the members of the recent document list while I am editing the document.
This is virtually impossible to test reproduce for most people. I have remote AFS mounts, but they are on the same LAN, and I've not noted any particular slowdown, granted this is not the same setup as that described.
You can simulate a slow network with the "Network Link Conditioner" that is part of Xcode: https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/WhyNetworkingIsHard/WhyNetworkingIsHard.html This might help to reproduce the issue.
I have also been hit by this. A theory I saw is that Libreoffice periodically does a QUERY_PATH_INFO through SMB requests. Link to the ask.libreoffice.org question: http://ask.libreoffice.org/en/question/36992/libreoffice-periodically-accesses-files-in-recent-list-causing-freezes/
Have tried some more now, and in my case it is completely related. If I clear my history and reopens the document from the share(therefore having only one item in the recent list), the periodical freezing is very short, perhaps a second or two. But if I then clear the list completely, all freezing goes away and LO becomes as responsive as one would expect. And this while editing a document I have on the network share(so *that's* not related). So I would agree with previous reporters that this is related to the recent-list.
Oh, and perhaps a point to people trying to reproduce the bug. To really notice the problem, the list of recent items should contain a few items. If you have a slow network(wireless, perhaps) connection then, LO becomes completely unworkable. It is almost constantly frozen and responds only each 20-30 seconds, then it freezes again.
(In reply to nicklasb from comment #11) > > > If you have a slow network(wireless, perhaps) connection then, LO becomes > completely unworkable. It is almost constantly frozen and responds only each > 20-30 seconds, then it freezes again. By any chance, if you monitor the processes running when the problem occurs, do you see a tccd process consuming disproportionate amounts of processor time ? Alex
I'm also affected by this problem: Ubuntu 14.04 LTS completely up-to-date with dist-upgrade Libreoffice 4.4.2.2 (40m0 Build:2) from ppa:libreoffice/libreoffice-4-4 We use davfs2 to mount an owncloud share. Unmounting the share fixes the problem. Also removing the "Recent Documents" from the toolbar temporarily fixes the problem
Somewhat along the same lines, I'm always dealing with the fact that libreoffice hangs completely if a mounted but now inaccessible fs is present. I have a GSA account at work, and if I am not online or not VPN'd in, libreoffice hangs completely, and indefinitely (so I can't clear recents, etc.). gedit also hangs in this situation, so this might be an issue outside of libreoffice's control. But if there's any way to handle inaccessible fs's, I'm for it.
*** Bug 94219 has been marked as a duplicate of this bug. ***
I can confirm this bug for a Ubuntu 15.04 system with LO 4.4.2.2. I have observed the exact same behaviour for quite a long time now, but do not either remember the exact LO version when it became annoying. Also here, emptying the list of recent documents returns LO to a usable state. Is there any workaround possible by setting the length of that list to 0? I can't find such a setting in the settings dialog.
Stephan: may your patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=93a0696e74e96e5a5ca821f33cb791b87e876f49 help here or I'm misleaded and it's not at all related?
(In reply to Julien Nabet from comment #17) > Stephan: may your patch > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=93a0696e74e96e5a5ca821f33cb791b87e876f49 help here or I'm misleaded and > it's not at all related? unrelated; this issue's original description is about Mac OS X; my patch is only relevant for Linux builds of LO with --enable-gio
*** Bug 95455 has been marked as a duplicate of this bug. ***
I can confirm the same issue in Ubuntu 14.04 LTS with LO 5.0.3.2. LO accesses files in the background. It freezes if system loses access to the share (lack of VPN connection, which is necessary for the access). Shares are mounted as such: /fsshare/home/...... /fsshare/work/...... fsshare itself is on the network and is mounted in the root dir.
I forgot to tell that I saw the file access through fatrace \ grep soffice.bin However, fatrace did not show any file access on the network (even though I specifically tried it with other applications). So it has something to do with the accessibility to the share folders (re-establishing VPN rescues freezing of LO) but fatrace is unable to see such IO.
Same as or different from bug 81640?
In my case different from bug 81640, because lags also occur, while user is working on local files only.
I want to make a correction, I mentioned earlier that I do not see any file access on the network. strace, however, showed access to network files, which are present in the resent document list. There is no obvious reason for LibreOffice to access those documents. That seems to be the main problem. I don't think solving this issue can be that hard. LO needs to access those files, only when user wants to access them.
I wonder, if anyone will pick this up? This actually affects everyone, who has files on network drives, which they access occasionally. For instance, many businesses, research institutes etc. have network drives, which people people access and work on their files. Then they lose access to those (e.g. come home) and LibreOffice is not working/hanging/freezing. This is very frustrating and from a programmer's perspective easy to solve. I don't program in C++ efficiently yet and LibreOffice code is not something I am familiar with. But I really don't get, why it tries to access files in the recent documents list, even though user doesn't want to open them. It is also clear that this is the problem. strace shows enormous amount of access to these files, which even seems to increase over time.
I have started using OpenOffice which doesn’t have the startup screen and therefore doesn’t suffer when network drives aren’t available.
Giuseppe: even if it's related to Recent docs part, thought you might be interested in this one since it concerns files from remote access.
Jamie: I tried to install OpenOffice, but it tried to replace soffice.bin and possibly breaking LibreOffice. At this point I am starting to give up.
Can someone test this bug with a recent daily master? Info: daily builds available at <http://dev-builds.libreoffice.org/daily/>. More information about daily builds use can be found at: <http://wiki.documentfoundation.org/Testing_Daily_Builds> Parallel installation for Mac users: <https://wiki.documentfoundation.org/Installing_in_parallel/OS_X>.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Florian Bruckner, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I just downloaded the latest beta - and this is still not fixed. We are experiencing this over a 100MBit VPN, recent documents list cleared. It happens via SMB and AFP.
Dear Florian Bruckner, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug