Bug 89394 - FILE MENU and HYPERLINKs: Freeze when UNC path is unavailable aka accessing remote server (e.g. SMB share) when off-line leads to hang / freeze / crash
Summary: FILE MENU and HYPERLINKs: Freeze when UNC path is unavailable aka accessing r...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
4.2.0.0.alpha0+ Master
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.0.0 target:5.2.0.1 target:5...
Keywords: haveBacktrace, notBibisectable, regression
: 82547 95763 98548 99376 99761 100895 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-02-15 15:15 UTC by Saren Tasciyan
Modified: 2017-10-31 18:35 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
LO crashlog (1.06 MB, text/plain)
2016-05-11 08:38 UTC, steve -_-
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Saren Tasciyan 2015-02-15 15:15:08 UTC
Samba files in registrymodifications.xcu causes hanging/freezing.

First I realized, my LibreOffice applications hang, whenever I click File menu for the first time. This takes up to a minute and is really annoying. Second clicking does not cause any freezing/hanging.

After a while I tried to insert a hyperlink in a Writer document. Following actions caused hanging/freezing repeatedly:
opening Insert/Hyperlink from the menu
typing in the "target" field in the hyperlink dialog (each key stroke!)

Assumption:
I have assumed that LibreOffice tried to reach a network location. I have previously worked several times on samba folders on different locations. These folders are disconnected during this behaviour.

Solution:
I found a solution about creating a new user profile and testing with folders from the old profile. So I replaced folders to see if these are the problem. Interestingly, none of the folders were cause of the problem but it was the registrymodifications.xcu file.

I investigated the contents of this text/xml file. There I found many files on samba locations. One of those files was the one I used several weeks ago. Location was something like this: file://10.0.0.5/.....
One problem was that there is only two "//" instead of three "///" like with other entries. I was not connected to this location during this behaviour. I removed this entry and restored old profile. So far there is no hanging/freezing.

Therefore, I file this bug for the programmers, who might be interested in. I think the continous hanging/freezing in hyperlink dialog is abnormal.

Cheers,
Saren Tasciyan
Comment 1 Saren Tasciyan 2015-02-15 22:02:34 UTC
Sorry for some lack of testing: for instance I did not (and I could not easily) test with a connection to the mentioned samba share. Also I did not try with three slashes "///", which I think is not the problem.
Comment 2 Jan 2015-02-23 10:31:10 UTC
I can confirm that slashes in hyperlinks to UNC paths are truncated in the link and in registrymodifications.xcu. \\your-server\path becomes file://your-server/path while intuitively should be file:///your-server/path instead.

Nevertheless, I cannot confirm the freeze/hang with my samba setup in Windows 7 with LO 4.2.4.2. I know similar hang problems with MS Word/Excel when UNC paths become unavailable but this does not seem to be the case here.

My steps: 
1. Open new writer document
2. Create Hyperlink to document on share \\your-server\path\doc.xlsx
3. Create another Hyperlink (no hang here)
3. Close writer
4. Start LO again
5. Use open dialog to open a document from a samba share (no hang)
6. Open previous document and add another hyperlink (no hang)

I verified that the path is in registrymodifications.xcu. Did I miss anything?

Setting to NEEDINFO. Please change back to UNCONFIRMED if you can provide more informations or steps to reproduce.
Comment 3 Saren Tasciyan 2015-02-23 10:41:54 UTC
Thanks for the comment. Do you think that in my case the IP-address but not domain name can be the reason for the problem?

Now I think maybe this scenario might explain the issue.
That location 10.0.0.5 was on a local network somewhere else. I am however at home on another local network with similar IPs delivered by the local DHCP server.
My address was: 10.10.244.118

Can it be that LibreOffice thinks I am on the same network, tries to connect it and thereby causing the freezing/hanging?
Comment 4 Jan 2015-02-23 10:48:57 UTC
Unfortunately, thats more a general issue. When opening files we have to provide some timeouts. Too small -> Some slow shares will fail. Too big -> Application hangs when share is not available.
Comment 5 Saren Tasciyan 2015-02-23 11:18:15 UTC
I see but an asynchronous approach can maybe help the issue. I am a programmer but I never looked into LO source code so I have no idea how it is designed. I am here as a user moreorless.

But I think the real issue here is that the hanging does not happen necessarily only while opening a file but opening the file menu. Displaying recent documents should not cause such an issue. Or even wierder inserting a hyperlink from the web should definetely not cause this problem imo.
Comment 6 Jan 2015-02-23 12:10:58 UTC
I totally agree. I can verify the problem on LO 4.4.0.3 on Windows.

Steps to reproduce:
1. Open registrymodifications.xcu and change a "HistoryItemRef" to "file://1.2.3.4/invalid/document.pptx".
2. Open LO (Dashboard). This will hang.
3. Open new writer document
4. Click on "File" Menu. This will hang.
5. Click on "Insert" -> "Hyperlink". This will also hang.

The bug is really annoying and LO will also not drop broken HistoryItemRefs. Usability/Productivity really suffers from this. Changing importance to high/major.
Comment 7 Saren Tasciyan 2015-02-25 18:10:27 UTC
Nice, I am happy to be able to contribute. Hopefully, I will also find time to be active on the development side in the future.
Comment 8 jmgigandet 2015-04-14 08:55:18 UTC
Hi,
I confirm the bug's still here in 4.4.4.2 (Windows 7 Pro 64 bits).
We have files stored on NAS at another office, and share them.
Clicking on File menu for the 1st time, may take more than one minute !
Regards,
Comment 9 Jan 2015-04-14 16:21:44 UTC
I did dig around in the source code and this looks like a regression from commit 93eefe54f5d6b6092371bad1e86444489d29eee2. See also: https://gerrit.libreoffice.org/5841. Setting to 4.2.0 as first affected version based on that.

We probably need to change this condition to properly detect UNC pathes on Windows (Linux uses smb:// which works):

if( !sUrl.startsWith("file://") || lcl_fileOpenable( sUrl ) ) {
// add file to list
}

File on disk: file:///C:/Users/abc/file.odp
File on UNC: file://server.domain.xx/share/file.odp

May be it should be !sUrl.startsWith("file:///")?
Comment 10 Stephan Bergmann 2015-04-15 07:47:31 UTC
I think the root problem is <http://cgit.freedesktop.org/libreoffice/core/commit/?id=93eefe54f5d6b6092371bad1e86444489d29eee2> "Make SvtHistoryOptions not return files if they can't be opened."  Trying an osl::File::open on a file URL cannot only block for noticeable amounts of time for URLs representing Windows UNC paths (which, indeed would syntactically be distinguishable from Windows file URLs not representing UNC paths, cf. <https://gerrit.libreoffice.org/#/c/15311/3> "tdf#89394. fix hangs because of unavailable Windows UNC path"), but also e.g. for file URLs on Linux representing NFS-accessed pathnames (that cannot syntactically be distinguished from file URLs representing local pathnames).

I suggest to revert 93eefe54f5d6b6092371bad1e86444489d29eee2 and instead implement its desired functionality in a way that avoids noticeable blocking of the UI.
Comment 11 Jan 2015-04-15 12:16:48 UTC
Despite my simple fix for UNC pathes I can imagine different solutions:
1. Drop the check (i.e., revert the old commit)
2. Find a magic check to determine if the file is local for every possible filesystem and OS. I don't thing this will ever be possible.
3. Check the files in a different thread. This would require significant UI changes

Local Linux NFS/Ceph/GlusterFS/SMB mounts will always have this problem. Same applies for local SMB mounts on Windows (binding a mount to a drive letter). So we either take option 1 and drop the feature. Alternatively, we implement 3 and make a lot of stuff asynchronous.

Can we at least merge my change for now? It will fix the problem for most users. Linux users (at least on gnome) do not suffer from this because it uses smb:// or nfs:// urls.
Comment 12 Commit Notification 2015-04-16 15:13:24 UTC
Jan Kantert committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3e55cf49f406076e1bdb491f8b3d484b766d5c72

tdf#89394. fix hangs because of unavailable Windows UNC path.

It will be available in 5.0.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 13 Stephan Bergmann 2015-04-16 15:19:50 UTC
(In reply to Jan from comment #11)
> Can we at least merge my change for now? It will fix the problem for most
> users. Linux users (at least on gnome) do not suffer from this because it
> uses smb:// or nfs:// urls.

Yes, the patch doesn't make anything worse, so I pushed it through now.  But I'd still highly recommend to get a proper fix for <http://cgit.freedesktop.org/libreoffice/core/commit/?id=93eefe54f5d6b6092371bad1e86444489d29eee2> "Make SvtHistoryOptions not return files if they can't be opened."  (And even on GNOME you only use nfs URLs when accessing NFS via GVFS, not when mounting it into the filesystem.)
Comment 14 Jan 2015-04-17 08:24:49 UTC
(In reply to Stephan Bergmann from comment #13)
> Yes, the patch doesn't make anything worse, so I pushed it through now.  But
> I'd still highly recommend to get a proper fix for
> <http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=93eefe54f5d6b6092371bad1e86444489d29eee2> "Make SvtHistoryOptions not
> return files if they can't be opened."  (And even on GNOME you only use nfs
> URLs when accessing NFS via GVFS, not when mounting it into the filesystem.)
I totally agree! Unfortunately, I do not feel confident to do the async UI changes. Also, I do not feel comfortable to just revert the old commit because I do not know if anybody relies on that feature.
Comment 15 Robinson Tryon (qubit) 2015-12-14 05:51:55 UTC Comment hidden (obsolete)
Comment 16 fanf42 2016-05-10 14:12:57 UTC
This happen also on Linux, and you can't just look at the file path to know where the file is, as stated in comment #10 here. See: https://bugs.documentfoundation.org/show_bug.cgi?id=99761

And really, just don't try to reach files that the user don't want to do anything with before you really have to. Related to that bug, I almost missed a major presentation to a customer, that was already NOT happy that I was using impress and not PowerPoint, because you really want to look to my 20 recents documents on an unreachable place and impress froze until I successfully clear the list when I just wanted to edit ONE file, passed in argument of the command line.
Comment 17 Aron Budea 2016-05-10 21:46:18 UTC
(In reply to fanf42 from comment #16)

Thanks for the additional detail on affected OSes, but please keep your comment relevant. I understand this bug caused you frustration, but this place is for bug reports, and not for venting. Yes, there are many bugs, no, there are not enough contributors to fix all of them. This is a community-driven project, and any help is welcome.
Comment 18 Aron Budea 2016-05-10 21:49:25 UTC
*** Bug 99761 has been marked as a duplicate of this bug. ***
Comment 19 Aron Budea 2016-05-11 08:26:42 UTC Comment hidden (obsolete)
Comment 20 steve -_- 2016-05-11 08:37:04 UTC
*** Bug 98548 has been marked as a duplicate of this bug. ***
Comment 21 steve -_- 2016-05-11 08:38:45 UTC
Created attachment 124968 [details]
LO crashlog
Comment 22 Aron Budea 2016-05-11 08:55:41 UTC
*** Bug 82547 has been marked as a duplicate of this bug. ***
Comment 23 Aron Budea 2016-05-11 09:04:19 UTC
https://bugs.documentfoundation.org/show_bug.cgi?id=82547#c2
An observation from Oyvind in bug 82547 is that there was some stuttering and SMB network traffic even during normal editing of the document.

I'm adding CCs from bug 82547 to this bug report.
Another early report of this issue was bug 71447, but it was closed because the issue wasn't observed anymore at some point of time in the past (but evidently it's still there).
Comment 24 Nicolas C. 2016-06-02 08:31:05 UTC
Hi

I also have the same issue with LibreOffice 4.4.3.2 (but was on previous versions as well), on Linux Mint 17.3

But the effect is larger than what is described: every contextual menu is very slow to appear if remote server ressource is not available (like right clicking to try to change picture size include a 30s wait for the menu to appear).

Clearing recent files makes LibreOffice usable again (but it takes 30 secondes to reach this option)
Comment 25 Commit Notification 2016-06-08 11:44:30 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a9e0f420181316fbbaae14f1afb58a49c77cb3a&h=libreoffice-5-2

Resolves: tdf#89394 revert attempt to ditch missing file from recent files

It will be available in 5.2.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 26 Commit Notification 2016-06-08 11:44:39 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7f25ccc81a35d2a89880cacf7835aa4b875f2ab2

Resolves: tdf#89394 revert attempt to ditch missing file from recent files

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 27 Caolán McNamara 2016-06-08 11:46:29 UTC
Lets revert. the original problem was a fairly cosmetic "annoyance" to have non-existing files in the recently used history, and the practical problem is much worse.

Probably will get hit a lot more in gtk native menus updates too than in the non-native case.
Comment 28 Commit Notification 2016-06-08 13:56:52 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=85bffd5ddd5364d2f750f74593cd9d2760ccbdbc&h=libreoffice-5-1

Resolves: tdf#89394 revert attempt to ditch missing file from recent files

It will be available in 5.1.5.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 29 Aron Budea 2016-07-19 00:18:26 UTC
*** Bug 95763 has been marked as a duplicate of this bug. ***
Comment 30 Aron Budea 2016-10-12 12:47:22 UTC
*** Bug 100895 has been marked as a duplicate of this bug. ***
Comment 31 Xisco Faulí 2017-10-31 18:35:15 UTC
*** Bug 99376 has been marked as a duplicate of this bug. ***