Arch Linux, x86_64, LibreOffice Version: 126.96.36.199, Build ID: 188.8.131.52 Arch Linux build-2 (regular release channel).
Self explanatory, Writer crashes very often while saving in the new rc/beta. This behavior is semi-random and does not always occur, but happens nearly all the time when an unsaved document is worked on for several minutes before saving.
Steps to reproduce:
Cannot be reproduced 100%, but editing an unsaved document and attempting to save several minutes later increases the chances dramatically.
Writer crashes with no warning, file recovery fails.
Writer should present file dialog and user should be able to save. Worst case should be that Writer crashes but auto-save and recovery should work.
Operating System: Linux (Other)
Version: 184.108.40.206 rc
Last worked in: 220.127.116.11 release
Possibly a duplicate of bug 69002
Did you install any LO specific extensions?
Did you try to rename your LO directory profile? (see https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux)
Finally, I know it might be tedious but since you don't know how to reproduce this easily, you can try to follow this
I can confirm this behaviour on CentOS x64, 5.10 with versions 18.104.22.168 and 22.214.171.124 either in i686 oder x64 versions. There is no difference. Using the original LO saving dialogs minimizes the danger of crashes on save a little. More on the 4.0.x, less on the 4.1.x. We currently running a LO 3.5 with no such issues.
On the 4.0.6 we get the crashes from time to time when a big document is saved or when multiple documents simultaneously are opened and edited and you try to save one of them. On 4.1.x you can force the crash when you do a big copy-n-paste from one open document to an other (new or edited). Then LO crashes reliably saving a document.
4.1.3 is most unstable and currently not useable for production at this point. The crash is 7 to 8 out of 10 saves. 4.0.6 seems more stable, it crashes 1 to 2 out of 20 or more.
A problem seem big spreadsheets, too. They crash on save very often. So it seems to me this is a memory problem.
We are running a X11 terminalserver, KDE 3.5, with 36GB or RAM, mostly 10GB to 14GB are unused. When running a 3.5 LO, it consumes a VSS of about 200000 to 300000. Regardless how many documents are open. All versions 4.x are starting(!) at 800000 and consume up to 16000000 and more. Per user!!! Increasing with time used, not with number or complexity of open documents.
Forgotten: my test users reported to me, that the crash nearly always comes when more than one document was open, or when LO stayed open and the documents where loaded one after one into the running instance. F.e.: start LO, open a document by file dialog, edit, save&close document, open next document and so on. Or loading documents one by one without save and close. After a while, saving isn't possible (the save dialog hangs and LO can only be closed by the window manager). Users who open a document (ether by the LO open dialog or via file manager konqueror), edit and do a save and QUIT LO have no such issues.
Both Writer and Calc behave the same for me under SUSE13.1 and Sabayon 14.01. I cannot either open a document or save a document. In all cases the app crashes without warning. Upon re-opening the app, it offers recovery but when I recover the file content is missint (a "new" document). Other apps seem to work fine, the problem is confined to libroffice as far as I can determine.
(In reply to comment #5)
> Both Writer and Calc behave the same for me under SUSE13.1 and Sabayon
> 14.01. I cannot either open a document or save a document. In all cases the
> app crashes without warning. Upon re-opening the app, it offers recovery
> but when I recover the file content is missint (a "new" document). Other
> apps seem to work fine, the problem is confined to libroffice as far as I
> can determine.
I am on openSUSE 13.1 I can confirm the crash with latest build.
Build ID: 0695236cd7347134e53c81cf15f38b61ffe13255
Here is the back trace after SIGSEGV:
This thread may help:
Miklos: should we put "notourbug"?
from comments #6 and #7 this is very likely a bug in "gtk2-engine-oxygen",
and can probably be worked around by using a different GTK+2 theme.