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
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.
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.
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?
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.
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.
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.
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.
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,
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:///")?
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.
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.
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.
(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.)
(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.
Migrating Whiteboard tags to Keywords: (notBibisectable) [NinjaEdit]
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.
(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.
*** Bug 99761 has been marked as a duplicate of this bug. ***
*** Bug 98548 has been marked as a duplicate of this bug. ***
Created attachment 124968 [details] LO crashlog
*** Bug 82547 has been marked as a duplicate of this bug. ***
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).
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)
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.
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.
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.
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.
*** Bug 95763 has been marked as a duplicate of this bug. ***
*** Bug 100895 has been marked as a duplicate of this bug. ***
*** Bug 99376 has been marked as a duplicate of this bug. ***