Bug 131850 - LibreOffice hangs if recent files are not accessible (e.g. remote samba, webdav, or nextcloud files)
Summary: LibreOffice hangs if recent files are not accessible (e.g. remote samba, webd...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:7.4.0 target:7.3.0.0.beta2 tar...
Keywords: bibisectNotNeeded, regression
: 134047 144972 146340 (view as bug list)
Depends on:
Blocks: Start-Center
  Show dependency treegraph
 
Reported: 2020-04-03 14:31 UTC by OfficeUser
Modified: 2022-02-03 11:47 UTC (History)
13 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Screenshot (98.65 KB, image/png)
2020-04-03 14:31 UTC, OfficeUser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description OfficeUser 2020-04-03 14:31:55 UTC
Created attachment 159302 [details]
Screenshot

Hi,

since using 6.4.2.2 I regularly experience the following regression:

Every time I start LibreOffice (the basic framework with recent file list icons; not a dedicated app) LO freezes for many seconds.

When I close LibreOffice documents of any type, LO hangs for longer times and sometimes shows failure message like the ones in my screenshot attached.

Some background information:
These issues seem to be provoked by the fact that my recent file list contains some files which are stored on remote-smb behind VPN. LibreOffice hangs as described above in case the VPN connection has been closed meanwhile so that some files from recent file list are not accessible.


I never experienced these issues with 6.3 builds. I assume there have been some modification to recent file list view in 6.4 branch.
Comment 1 Mike Kaganski 2020-04-06 08:15:44 UTC
I don't think it's related to 6.4. The problem of bug 89394 was re-introduced with https://git.libreoffice.org/core/+/43446fa03995fb5d1379fc0afbeec36c9dedfde2, where each shown file was read to check if it's encrypted. That was for v.6.1.

Steps to reproduce:

1. Open registrymodifications.xcu in the user profile [1];
2. Replace all "/org.openoffice.Office.Histories/Histories/org.openoffice.Office.Histories:HistoryInfo['PickList']" entries with these two lines:

> <item oor:path="/org.openoffice.Office.Histories/Histories/org.openoffice.Office.Histories:HistoryInfo['PickList']/ItemList"><node oor:name="http://1.2.3.4/doc.odt" oor:op="replace"><prop oor:name="Title" oor:op="fuse"><value>pwdLorem</value></prop><prop oor:name="Filter" oor:op="fuse"><value>writer8</value></prop><prop oor:name="Password" oor:op="fuse"><value></value></prop></node></item>
> <item oor:path="/org.openoffice.Office.Histories/Histories/org.openoffice.Office.Histories:HistoryInfo['PickList']/OrderList"><node oor:name="0" oor:op="replace"><prop oor:name="HistoryItemRef" oor:op="fuse"><value>http://1.2.3.4/doc.odt</value></prop></node></item>

3. Try to start LibreOffice.

=> it will take between 20 and 30 s to launch, because it would try to access http://1.2.3.4/doc.odt, which does not immediately reject, and thus the read attempt will timeout before the load will continue.

Tested with Version: 6.1.5.2 (x64)
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU threads: 12; OS: Windows 10.0; UI render: GL; 
Locale: ru-RU (ru_RU); Calc: group threaded

OK in Version: 6.0.0.1 (x64)
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a
CPU threads: 12; OS: Windows 10.0; UI render: default; 
Locale: en-US (ru_RU); Calc: group

A proper fix would be drawing default *module* thumbnail on opening start center (detected from document extension, or from last used filter, which is available in the entries, i.e. without any actual file access); then retrieve all necessary information (encrypted status, availability (bug 101302), anything else) asynchronously in multiple threads, updating the thumbnails as the data is available.

[1] https://wiki.documentfoundation.org/UserProfile
Comment 2 Maxim Monastirsky 2020-06-17 08:07:38 UTC
*** Bug 134047 has been marked as a duplicate of this bug. ***
Comment 3 bugzilla2 2020-06-17 08:39:47 UTC
(In reply to Mike Kaganski from comment #1)
> I don't think it's related to 6.4. The problem of bug 89394 was
> re-introduced with
> https://git.libreoffice.org/core/+/43446fa03995fb5d1379fc0afbeec36c9dedfde2,
> where each shown file was read to check if it's encrypted. That was for
> v.6.1.

I doubt that, because I can clearly reproduce this behavior with 6.4 but NOT with 6.3. So I still believe that the introduction of the Icon-Overlay in Start Center in 6.4 is the reason for this regression. I'd prefer to set earliest affected version back to 6.4.x.

In the end, it doesn't matter if its due to encryption-check or mime-type sniffing, loading start center should NOT trigger access to all recent files.
Comment 4 bugzilla2 2020-06-17 08:48:38 UTC
(In reply to OfficeUser from comment #0)

I'd suggest changing the title of this bug from "LibreOffice hangs if recent files are not accessible" to "Start Center hangs if recent files are not accessible" or "LibreOffice Start Center hangs if recent files are not accessible" (even though its obvious that it belongs to LibreOffice, since its the LibreOffice Bugtracker ;)). I think this bug would be easier to find with the Tag "Start Center" in the title. I could change it my own, but I don't want to override you ;)
Comment 5 Mike Kaganski 2020-06-17 09:12:51 UTC
(In reply to bugzilla2 from comment #3)

It might of course had worsened with the fix for tdf#125756. However, that partial regression is undoubtedly not to be fixed by its own, and the core problem *is* the one introduced in the commit mentioned in comment 1. Please do not change the earliest version, since it's analyzed, the problem identified, and the proper way to fix described.
Comment 6 Maxim Monastirsky 2020-06-17 09:31:13 UTC
(In reply to Mike Kaganski from comment #5)
> It might of course had worsened with the fix for tdf#125756. However, that
> partial regression is undoubtedly not to be fixed by its own
I disagree. There's absolutely no reason to check for encryption status while just getting the default image for the given module to be used as an overlay. But that exactly what the overlay code does, by calling RecentDocsView::getDefaultThumbnail which has the encryption check. Before introducing the overlay feature, the encryption check was triggered only for files which didn't have thumbnails stored in the user profile, which usually not the case.

> and the core problem *is* the one introduced in the commit mentioned in comment 1.
Note that for the case there is no thumbnail in the user profile, we were trying to read the file anyway to get the thumbnail stored inside it, way before the mentioned commit.
Comment 7 Heiko Tietze 2020-06-17 09:45:12 UTC
It was kind of copy/paste coding. I agree with removing the encryption part from the thumbnail as this information does not contribute to the actual reason for the MIME type icon, to see what content a file contain resp. what module would be used.
Comment 8 Mike Kaganski 2020-06-17 09:52:44 UTC
(In reply to Maxim Monastirsky from comment #6)
> > and the core problem *is* the one introduced in the commit mentioned in comment 1.
> Note that for the case there is no thumbnail in the user profile, we were
> trying to read the file anyway to get the thumbnail stored inside it, way
> before the mentioned commit.

You mean the "aThumbnail = ThumbnailView::readThumbnail(rURL);" call in RecentDocsViewItem::RecentDocsViewItem? Yes. Still, it needs to be also done in a dedicated thread.

But I see your point, and taking the overlay icon is of course should be re-implemented to not try to read encrypted status.
Comment 9 bugzilla2 2020-07-10 12:25:05 UTC
Bug still present in 6.4.5.2
Comment 10 Mike Kaganski 2021-03-08 12:46:12 UTC
*** Bug 140875 has been marked as a duplicate of this bug. ***
Comment 11 Michael Warner 2021-10-21 13:17:57 UTC
*** Bug 144972 has been marked as a duplicate of this bug. ***
Comment 12 Kevin Suo 2021-12-14 09:52:04 UTC
*** Bug 146219 has been marked as a duplicate of this bug. ***
Comment 13 Eyal Rozenberg 2021-12-14 19:56:55 UTC
Is this bug supposed to be about remote files only, or also about local files which have become inaccessible?

If it's the former, than my dupe is not a dupe; and if it's the latter, then the title is a bit misleading.
Comment 14 Kevin Suo 2021-12-15 05:58:24 UTC
(In reply to Eyal Rozenberg from comment #13)
I reproduce the issue regarding remove files on Nextcloud (webdav), but I do not reproduce the hang with a local file deleted. So if it is slow or hangs with deleted local file, then it should not be a duplicate.

> If it's the former, than my dupe is not a dupe
But which bug are you referring to?
Comment 15 Mike Kaganski 2021-12-15 06:24:41 UTC
https://gerrit.libreoffice.org/c/core/+/126849
Comment 16 Commit Notification 2021-12-15 07:18:22 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/2f848eb5dc6f6f9344f250ac9860065130aaf436

tdf#131850: avoid encryption check for recent docs overlay

It will be available in 7.4.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 17 Mike Kaganski 2021-12-15 07:22:38 UTC
The regression from https://git.libreoffice.org/core/+/d43c6fa220524a09c0b24cbb5bc03c4456cd2515 is now fixed. Note that for password-protected files, the check will still be made, because their thumbnails are not stored in the thumbnail cache. One possible way forward (in addition to proper async IO) could be storing generic thumbnail in cache for password-protected files - but that would be theming-unfriendly, since it would show "alien" thumbnails after user changes icon theme.

See comment 1, and use bug 101302 for the rest.
Comment 18 Eyal Rozenberg 2021-12-15 07:34:12 UTC
(In reply to Kevin Suo from comment #14)
> But which bug are you referring to?

Bug 140875.
Comment 19 Mike Kaganski 2021-12-15 07:48:23 UTC
(In reply to Eyal Rozenberg from comment #18)
> Bug 140875.

... which was unduped by yourself on 2021-03-08 (for no good reason but misunderstanding the workflow and goals of the bug tracker): https://bugs.documentfoundation.org/show_activity.cgi?id=140875
Comment 20 Kevin Suo 2021-12-15 07:58:13 UTC
(In reply to Mike Kaganski from comment #17)

The hang/slowness still exists with the following scenario:
1. Mount a webdav folder in your system using the file manager.
2. Open a file with LibreOffice from the mounted webdav folder, then quit libreoffice.
3. Unmount the webdav folder from your file manager.
4. Run libreoffice.

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 453c5b6214654b440fe1d3e926cddfb695e17f10
CPU threads: 8; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN
Build Platform: Fedora34@X64, Branch:master, bibisect-linux-64-7.4-CN
Calc: threaded
Comment 21 Mike Kaganski 2021-12-15 08:03:11 UTC
(In reply to Kevin Suo from comment #20)

Could you please check which call stack produces the hang? Thanks!
Comment 22 Kevin Suo 2021-12-15 09:09:14 UTC
(In reply to Mike Kaganski from comment #21)

Will try, but I guess it's in:
sfx2/source/control/recentdocsview.cxx:73

bool IsDocEncrypted(const OUString& rURL)
{
...
        uno::Sequence<uno::Any> aArgs{ uno::Any(rURL), uno::Any(embed::ElementModes::READ) };
        uno::Reference<embed::XStorage> xDocStorage (
            xStorageFactory->createInstanceWithArguments(aArgs),
            uno::UNO_QUERY);
...
}

In case the rURL is a remote file, it tries to read that file to check if it is encrypted. In my opinion we should not check encryption for remote files when we start up the application. Check encryption is only needed when we click that remote file for viewing or editing (so that the user need to provide a password). Otherwise, if is certainly slow especially if the network is slow.

I am aware that to draw the thumbnail we need to read that file. But is it really useful to draw a thumbnail for the remote files? How about cache the remote file thumbnail at the time when that file was initially opened, or simply draw a dummy/generic thumbnail for all those remote files?
Comment 23 Mike Kaganski 2021-12-15 09:14:06 UTC
(In reply to Kevin Suo from comment #22)

The commit above made sure that when there is a cached thumbnail of a document (no matter if it's local or remote, and unencrypted remote files should have that cached thumbnail), the encrypted status is *not* checked. So if *that* still happens, then we need a call stack to try to understand what goes on; but I *suppose* there might be another place that does that - which then needs an own issue.

Wrt not checking remote files - that's not possible, since great proportion of work - especially in corporate use of office suites - happens exactly with remote documents, so treating them as second-class citizens is wrong.
Comment 24 Commit Notification 2021-12-15 10:36:51 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-3":

https://git.libreoffice.org/core/commit/214364584d3a247a70eed42ca7101b675125bf43

tdf#131850: avoid encryption check for recent docs overlay

It will be available in 7.3.0.0.beta2.

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

Affected users are encouraged to test the fix and report feedback.
Comment 25 Eyal Rozenberg 2021-12-15 18:16:29 UTC
(In reply to Mike Kaganski from comment #23)
> Wrt not checking remote files - that's not possible, since great proportion
> of work - especially in corporate use of office suites - happens exactly
> with remote documents, so treating them as second-class citizens is wrong.

I don't believe your metaphor works here. Documents are not like people. In particular - how about drawing the thumbnail asynchronously if it's not cached? i.e. start with no-thumbnail, let user proceed with their interaction, and as soon as the thumbnail is available, draw it?
Comment 26 Mike Kaganski 2021-12-15 20:25:39 UTC
(In reply to Eyal Rozenberg from comment #25)
> how about drawing the thumbnail asynchronously if it's not
> cached? i.e. start with no-thumbnail, let user proceed with their
> interaction, and as soon as the thumbnail is available, draw it?

Sometimes I doubt people can read. After I wrote in comment 1:

(In reply to Mike Kaganski from comment #1)
> A proper fix would be drawing default *module* thumbnail on opening start
> center (detected from document extension, or from last used filter, which is
> available in the entries, i.e. without any actual file access); then
> retrieve all necessary information (encrypted status, availability (bug
> 101302), anything else) asynchronously in multiple threads, updating the
> thumbnails as the data is available.

... after I referred to that in comment 17; after I repeated that in bug 101302 comment 32 (confirming what Maxim wrote in bug 101302 comment 8), I get someone suggesting me to consider async IO. Oh my!...
Comment 27 Eyal Rozenberg 2021-12-15 20:51:14 UTC
(In reply to Mike Kaganski from comment #26)
Sorry.
Comment 28 Commit Notification 2021-12-16 11:12:33 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/bda87ece5bd8755384213aa6b01524324c153893

tdf#131850: avoid encryption check for recent docs overlay

It will be available in 7.2.6.

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

Affected users are encouraged to test the fix and report feedback.
Comment 29 bugzilla2 2021-12-16 11:54:06 UTC
(In reply to Commit Notification from comment #28)
> Mike Kaganski committed a patch related to this issue.
> It has been pushed to "libreoffice-7-2":
> 
> It will be available in 7.2.6.
 
Thanks for the Patch, can't wait to see that in production builds :)
Comment 30 Commit Notification 2021-12-17 09:36:25 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-7-2-5":

https://git.libreoffice.org/core/commit/ea5c9ca9950a23860daaccb658bdbed76a038a2a

tdf#131850: avoid encryption check for recent docs overlay

It will be available in 7.2.5.

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

Affected users are encouraged to test the fix and report feedback.
Comment 31 Buovjaga 2022-01-04 15:46:04 UTC
*** Bug 146340 has been marked as a duplicate of this bug. ***
Comment 32 fnorbenden 2022-01-10 19:05:46 UTC
Following an update to 7.2.5 I did the following:

1. Worked on odt files on a remote share mounted using ssh through my vpn.
2. Closed LO.
3. Unmounted the share.
4. Disconnected the VPN.
5. Attempted to open a local file, via referrer (firefox) and through terminal.

LO froze on boot every time.

Libreoffice 7.2.5.1-1.6.x86_64
OpenSuSE Tumbleweed 5.14.11-1

Can't get any more information because LO won't launch.
Comment 33 Kevin Suo 2022-01-10 23:23:38 UTC
(In reply to fnorbenden from comment #32)
You may rename you lo user profile so that it starts with a fresh one, to continue with your work:
/home/<your_username>/.config/libreoffice
Comment 34 Timo Jyrinki 2022-02-03 07:27:36 UTC
*** Bug 147152 has been marked as a duplicate of this bug. ***
Comment 35 Timo Jyrinki 2022-02-03 07:33:12 UTC
See ^ duplicate bug for my workarounds, either removal of sftp entries from registrymodifications.xcu or disabling recent documents.

So can you conifrm if 7.2.5.1 relesed on 2021-Dec-14 is not new enough (this is the version I'm using), but 7.2.5.2 released on 2021-Dec-29 would be?
Comment 36 Kevin Suo 2022-02-03 11:47:11 UTC
(In reply to Timo Jyrinki from comment #35)
Commit ea5c9ca9950a23860daaccb658bdbed76a038a2a was applied to libreoffice-7-2 on Fri Dec 17 10:35:41 2021 +0100.

So, yes, the fix is available in 7.2.5.2 (i.e. 7.2.5 RC2, i.e. the final 7.2.5 version you can download from the https://www.libreoffice.org/download/ link), but not in 7.2.5.1 (i.e. 7.2.5 RC1).