Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
# splt up the LO and kio parts properly clone 1069835 -1 reassign -1 kio retitle -1 kio: Don't leak existing file handles to newly spanwed KIO workers block 1069835 by -1 # LOs part is done, at least for this one. close 1069835 4:24.2.2-1 thanks Am 03.05.24 um 10:54 schrieb Andreas B. Mundt: On Fri, May 03, 2024 at 10:18:22AM +0200, Sune Stolborg Vuorela wrote: On Friday, May 3, 2024 10:06:27 AM CEST you wrote: On Thu, May 02, 2024 at 04:37:30PM +0200, Sune Stolborg Vuorela wrote: […] If it works for you, I'll ask the debian kde maintainers to fix it. It looks like it fixes the libreoffice issue (no modifications applied to libreoffice). With a patched kio package I was not able to reproduce the issue. Replacing just the kio binary package seems to be sufficient. We are going to test a bit more on other setups too. Tested with libreoffice from bookworm-backports: Fixed. Cool. So that means we don't even need the LO part here? The changes needed to libreoffice are already in Debian ( https:// gerrit.libreoffice.org/c/core/+/162935 ) - also by Kevin Ottens who also authored this patch. Great! Yes, that is the one mentioned earlier and fixed in 24.2.2. Cleaning those bugs up and making an own one for kio. Regards, Rene
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Control: tags -1 + patch
Hi Sune!
On Fri, May 03, 2024 at 10:18:22AM +0200, Sune Stolborg Vuorela wrote:
> On Friday, May 3, 2024 10:06:27 AM CEST you wrote:
> > On Thu, May 02, 2024 at 04:37:30PM +0200, Sune Stolborg Vuorela wrote:
> > > […]
> > >
> > > If it works for you, I'll ask the debian kde maintainers to fix it.
> > >
> > It looks like it fixes the libreoffice issue (no modifications applied
> > to libreoffice). With a patched kio package I was not able to
> > reproduce the issue. Replacing just the kio binary package seems to
> > be sufficient. We are going to test a bit more on other setups too.
Tested with libreoffice from bookworm-backports: Fixed.
> The changes needed to libreoffice are already in Debian ( https://
> gerrit.libreoffice.org/c/core/+/162935 ) - also by Kevin Ottens who also
> authored this patch.
Great!
> […]
>
> For the ark issue, you need the two kio patches I referenced in the bug report
> - also patches by Kevin Ottens
> https://invent.kde.org/frameworks/kio/-/commit/3e6800b37
> https://invent.kde.org/frameworks/kio/-/commit/48322f443
Attached is the slightly modified patch (only context, to apply cleanly).
Best regards,
Andi
>From d1a2dab1da43d613ae5a8459ddcb62c8d78c46ff Mon Sep 17 00:00:00 2001
From: Kevin Ottens
Date: Fri, 5 Jan 2024 11:51:49 +0100
Subject: [PATCH] Don't leak file descriptors when spawning new workers
By default we inherit file descriptors from the parent in
the worker process. This is a leak of resources since the
worker won't be able to do anything with them. Also, in
the case of CIFS this causes locks which might lead to bad
surprises in the parent process.
---
Index: kio-5.103.0/src/kioslave/kioslave.cpp
===
--- kio-5.103.0.orig/src/kioslave/kioslave.cpp
+++ kio-5.103.0/src/kioslave/kioslave.cpp
@@ -18,6 +18,10 @@
#include
#include
+#ifdef Q_OS_UNIX
+#include
+#endif
+
#ifdef Q_OS_WIN
#include
#include
@@ -40,6 +44,17 @@ extern "C" KIO::AuthInfo *_kioslave_init
int main(int argc, char **argv)
{
+#ifdef Q_OS_UNIX
+int max_fd = INT_MAX;
+struct rlimit limit;
+if (getrlimit(RLIMIT_NOFILE, ) == 0) {
+max_fd = limit.rlim_cur;
+}
+for (int fd = STDERR_FILENO + 1; fd < max_fd; fd++) {
+::close(fd);
+}
+#endif
+
if (argc < 5) {
fprintf(stderr, "Usage: kioslave5\n\nThis program is part of KDE.\n");
return 1;
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Control: found -1 libreoffice/4:24.2.3~rc1-3 Control: notfixed -1 libreoffice/4:24.2.2-1 Control: reopen -1 Control: tags -1 - moreinfo Hi again, On Thu, Apr 25, 2024 at 06:43:17PM +0200, Rene Engelhard wrote: > Am 25.04.24 um 18:37 schrieb Andreas B. Mundt: > > On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote: > > > Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: > > > > For now, we traced the issue back to libreoffice-kf5. If this package > > > > is removed, neither the document disappears on closing libreoffice nor > > > > the popup is shown when 'nobrl' is removed from the mount options. > > > Which doesn't do IO itself though? But maybe the KDE file picker (over > > > kio) > > > does something weird? But saving (ttbomk) isn't done by the file picker > > > itself? > > I just tried a trixie XFCE desktop and cannot reproduce the issue > > there. Then I installed KDE and switched the DE. In KDE again the > > issue is reproducable, removing libreoffice-kf5 makes the problem go > > away. Installing libreoffice-kf5 again: Issue is back. > Shrugs. > > However, back in XFCE, even with libreoffice-kf5 installed, the issue > > does not show up. > > Because in XFCE you don't get the KDE File Picker but the Gtk one. > > Unless you force kf5, which I don't think you do. Right. > > The different file chooser GUIs seem to trigger the > > issue. > Interesting. > > Removing libreoffice-kf5 or switching to XFCE results in a > > different file chooser, which somehow causes the problem. So the bug > > is probably not in libreoffice-kf5 … > > -kf5 does contain the KDE file picker used in LibreOffice. > > > In any case, try with >= 24.2.2 (so sid). If that commit was it (which I > somehow doubt, see my previous reply) sid should work. I upgraded libreoffice to the version in sid now -- it seems not to happen as often as before, but I could reproduce it still a few more times. Not sure which package to reassign the bug to. Best regards, Andi
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Control: found -1 libreoffice/4:24.2.0-1 Hi Rene, thanks for your quick reply and sorry for not providing detailed version information! On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote: > > Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: > > For now, we traced the issue back to libreoffice-kf5. If this package > > is removed, neither the document disappears on closing libreoffice nor > > the popup is shown when 'nobrl' is removed from the mount options. > > Which doesn't do IO itself though? But maybe the KDE file picker (over kio) > does something weird? But saving (ttbomk) isn't done by the file picker > itself? I just tried a trixie XFCE desktop and cannot reproduce the issue there. Then I installed KDE and switched the DE. In KDE again the issue is reproducable, removing libreoffice-kf5 makes the problem go away. Installing libreoffice-kf5 again: Issue is back. However, back in XFCE, even with libreoffice-kf5 installed, the issue does not show up. The different file chooser GUIs seem to trigger the issue. Removing libreoffice-kf5 or switching to XFCE results in a different file chooser, which somehow causes the problem. So the bug is probably not in libreoffice-kf5 … Best regards, Andi
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Hi, Am 25.04.24 um 18:37 schrieb Andreas B. Mundt: On Thu, Apr 25, 2024 at 05:43:29PM +0200, Rene Engelhard wrote: Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: For now, we traced the issue back to libreoffice-kf5. If this package is removed, neither the document disappears on closing libreoffice nor the popup is shown when 'nobrl' is removed from the mount options. Which doesn't do IO itself though? But maybe the KDE file picker (over kio) does something weird? But saving (ttbomk) isn't done by the file picker itself? I just tried a trixie XFCE desktop and cannot reproduce the issue there. Then I installed KDE and switched the DE. In KDE again the issue is reproducable, removing libreoffice-kf5 makes the problem go away. Installing libreoffice-kf5 again: Issue is back. Shrugs. However, back in XFCE, even with libreoffice-kf5 installed, the issue does not show up. Because in XFCE you don't get the KDE File Picker but the Gtk one. Unless you force kf5, which I don't think you do. The different file chooser GUIs seem to trigger the issue. Interesting. Removing libreoffice-kf5 or switching to XFCE results in a different file chooser, which somehow causes the problem. So the bug is probably not in libreoffice-kf5 … -kf5 does contain the KDE file picker used in LibreOffice. In any case, try with >= 24.2.2 (so sid). If that commit was it (which I somehow doubt, see my previous reply) sid should work. Regards, Rene
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Hi, Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: For now, we traced the issue back to libreoffice-kf5. If this package is removed, neither the document disappears on closing libreoffice nor the popup is shown when 'nobrl' is removed from the mount options. Which doesn't do IO itself though? But maybe the KDE file picker (over kio) does something weird? But saving (ttbomk) isn't done by the file picker itself? There also is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935182 since some time. It looks a bit like the issue found in [2]. Which doesn't touch any KDE stuff either. In fact it caused 32bit builds to fail[1] and I don't know what more regressions this caused. I would be wary of "just" backporting it in a point release... Regards, Rene [1] by relying on internal glibc/kernel types, see https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/libreoffice_24.2.2_rc1-2/patches/fix-32bit-build.diff?ref_type=tags - later updated upstream for https://cgit.freedesktop.org/libreoffice/core/commit/sal/osl/unx/file.cxx?id=434065478d35fe8e144aec916ac06438c0150270
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
close 1069835 4:24.2.2-1 forwarded 1069835 https://bugs.documentfoundation.org/show_bug.cgi?id=55004 tag 1069835 + moreinfo thanks Am 25.04.24 um 17:03 schrieb Andreas B. Mundt: Package: libreoffice-kf5 Version? Severity: grave Come on... Not downgrading just yet, but I don't believe it's grave. we run Debian bookworm KDE plasma clients with home directories mounted from an SMB share. From time to time, users reported that Ah, bookworm. You should have mentioned it in Version: libreoffice documents have disappeared completely when closing libreoffice. We were now able to reproduce the issue on both, the current bookworm and bookworm-backports version of libreoffice. Mount an SMB share. I use the following in fstab: //SHARE/DIR /media/share cifs user,nobrl,user=USER,password=PASS 0 0 Open/create an ODT document, write some text, save the file and check it's appearance on the share. Then click Insert → Image and (perhaps with the image still selected in the document) close libreoffice. The file disappears on the share. This is almost always reproducible (we tested multiple SMB servers) if not, just open the file again, insert another image, Ctrl-S, Ctrl-Q, the file is gone! If 'nobrl' is removed from the mount options (but we need it for other programs to work properly), instead of the file disappearing, a popup shows: Error saving the document Untitled 1: Error creating object. Could not create backup copy. This looks like already reported upstream [1]. For now, we traced the issue back to libreoffice-kf5. If this package is removed, neither the document disappears on closing libreoffice nor the popup is shown when 'nobrl' It looks a bit like the issue found in [2]. So fixed in sid? (If I only could update the bookworm backport to 24.2.2+, but given it's sstill stuck behind time_t...) Regards, Rene
Bug#1069835: libreoffice-kf5: documents may get lost on SMB shares
Package: libreoffice-kf5 Severity: grave Dear Rene, everybody, we run Debian bookworm KDE plasma clients with home directories mounted from an SMB share. From time to time, users reported that libreoffice documents have disappeared completely when closing libreoffice. We were now able to reproduce the issue on both, the current bookworm and bookworm-backports version of libreoffice. Mount an SMB share. I use the following in fstab: //SHARE/DIR /media/share cifs user,nobrl,user=USER,password=PASS 0 0 Open/create an ODT document, write some text, save the file and check it's appearance on the share. Then click Insert → Image and (perhaps with the image still selected in the document) close libreoffice. The file disappears on the share. This is almost always reproducible (we tested multiple SMB servers) if not, just open the file again, insert another image, Ctrl-S, Ctrl-Q, the file is gone! If 'nobrl' is removed from the mount options (but we need it for other programs to work properly), instead of the file disappearing, a popup shows: Error saving the document Untitled 1: Error creating object. Could not create backup copy. This looks like already reported upstream [1]. For now, we traced the issue back to libreoffice-kf5. If this package is removed, neither the document disappears on closing libreoffice nor the popup is shown when 'nobrl' is removed from the mount options. It looks a bit like the issue found in [2]. Thanks for maintaining libreoffice, best regards, Andi [1] https://bugs.documentfoundation.org/show_bug.cgi?id=160315 [2] https://bugs.documentfoundation.org/show_bug.cgi?id=55004#c56
