Bug 147152 - Recent document pointers to a network (sftp) storage currently not available hang LibreOffice on startup
Summary: Recent document pointers to a network (sftp) storage currently not available ...
Status: RESOLVED DUPLICATE of bug 146219
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected)
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2022-02-03 07:26 UTC by Timo Jyrinki
Modified: 2022-02-03 10:39 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

call stack when seemingly hanged on startup (7.94 KB, text/plain)
2022-02-03 09:37 UTC, Timo Jyrinki

Note You need to log in before you can comment on or make changes to this bug.
Description Timo Jyrinki 2022-02-03 07:26:12 UTC
# Test case:

1. Mount eg gvfs sftp file share and open a document from there.
2. Close LO, unmount the share
3. Start LO

# Observed behavior:

LibreOffice hangs indefinitely.

# Excepted behavior:

Do not try to access all files in recent documents on startup, and even later if accessing on user's request do a timeout with error message.

# Workaround 1:

Before every LO startup, one can run:

> sed -i '/sftp/d' ~/.config/libreoffice/4/user/registrymodifications.xcu

Which for example in this case removes lines like:

> <item oor:path="/org.openoffice.Office.Histories/Histories/org.openoffice.Office.Histories:HistoryInfo['PickList']/OrderList"><node oor:name="8" oor:op="replace"><prop oor:name="HistoryItemRef" oor:op="fuse"><value>sftp://olo/home/timo/Asiakirjat/kauppalaskut.ods</value></prop></node></item>

# Workaround 2:

Follow https://www.libreofficehelp.com/how-to-delete-recent-documents-list-in-libreoffice/ and set the value to 0 to disable recent documents.

# History:

This is only a gut feeling / vague memories but this may heve gotten worse somewhere in LO 7.x - it used to be it timed out, now it seems like a complete hang.


I'm happy to help debugging if anyone tells me what/how to debug/run (I can follow technical debugging instructions) - the wiki instructions seem just a bit broad and I wouldn't know what exactly to provide.
Comment 1 Timo Jyrinki 2022-02-03 07:27:36 UTC
Doh, now I found immediately 131850 after filing this.

I'm using 7.2.5, will re-test with 7.2.6 later.

*** This bug has been marked as a duplicate of bug 131850 ***
Comment 2 Mike Kaganski 2022-02-03 07:57:29 UTC
It should not be a duplicate. 7.2.5 already includes a fix for the specific problem in bug 131850; and there may be other problems in other scenarios, like this one - maybe we have some special processing for the sftp URLs. Needs reproducing, debugging and separate fixing; so this needs an own issue - like here.
Comment 3 Timo Jyrinki 2022-02-03 08:13:43 UTC
Ok then, reopening. Indeed I have
Comment 4 Mike Kaganski 2022-02-03 08:35:02 UTC
Could you please check which call stack produces the hang? Thanks!
Comment 5 Alex Thurgood 2022-02-03 08:47:39 UTC
@Timo : you might also be interested in the discussion here if it is going to affect the way you use your ftp server with LO, e.g if your documents contain links to other FTP hosted documents :

Comment 6 Buovjaga 2022-02-03 08:52:56 UTC
SFTP is a different protocol, though: https://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol
Comment 7 Timo Jyrinki 2022-02-03 09:37:56 UTC
Created attachment 178009 [details]
call stack when seemingly hanged on startup

Indeed sftp is essentially SSH, not related to the ftp in anyway other than a poor name.

Obviously I couldn't first reproduce it anymore, but here it is. It does not seem to affect all sftp urls, for some reason, but after opening various odt and ods files on some servers I now have a (saved) registrymodifications.xcu that produces the problem. The problem disappears if removing all 'sftp' containing lines there, and reappears if I restore the lines.

Furthermore, it seems that after 1min or so waiting the LO finally launches, I'm not 100% certain of my previous statement that there would be cases where it would never launch (although another person reported so as well to me at some point).
Comment 8 Mike Kaganski 2022-02-03 10:23:57 UTC
(In reply to Timo Jyrinki from comment #7)

Thank you!
This is bug 146219.

*** This bug has been marked as a duplicate of bug 146219 ***
Comment 9 Mike Kaganski 2022-02-03 10:28:36 UTC
(In reply to Mike Kaganski from comment #8)
> This is bug 146219.

... and is only available in
Comment 10 Timo Jyrinki 2022-02-03 10:39:24 UTC
Thank you! I'll make sure to re-test later on with, it should hit openSUSE Tumbleweed soon.