This bug was filed from the crash reporting server and is br-8bd444e9-2dc6-492a-a312-c813d1de5876. ========================================= Observed behaviour: Crash during editing a database document (queries, forms). Also open: Two spreadsheet documents and one text document. After restarting LibreOffice the splash screen appears and disappears a few times per second. It seems to follow the mouse pointer, i.e. appears on the monitor which displays the mouse pointer. Sometimes Base seems to produce several hundreds or thousands of backup files at a rate of some files per second. This time the backup-directory showed only two backup files: one for a spreadsheet document, one for the database document. As the splash screen loop seemed not to be related to an excess number of backup files I aborted the soffice process structure. The task manager did not show the LibreOffice process - the resource monitor did. Aborting was difficult as the repetitions of the splash screen interfered with the dialogue boxes of the resource monitor. I think it was at this time when the crash dump was created. Restarting LibreOffice again showed the usual document recovery screen. Recovery seemed to work as usual. Installed extensions APSO, MRI and PlantUML did not work anymore: In the user profile parts of the uno_packages/cache directory tree were missing. Restoring this directory from git seems to have fixed this problem. Expected behaviour: - Base should not crash in the first place - On restart after a crash a document recovery screen should appear, not a infinite loop of splash screens - The crash should not destroy installed extensions How to reproduce: Don't know, happens from time to time, seems to be related to Base.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Finding repro steps may be the hard part of this bug. That's why I uploaded three crash reports together with bug reports (this one, bug 146943 and bug 146944 ) to demonstrate that the bug is there and it happens way to often. Nevertheless I gave it a try: The crash reported in bug 146944 occurred in a simple setting and it was easy to create a broken document that makes Writer report macros that do not exist. But using this document I was not able to reproduce any crash. See https://bugs.documentfoundation.org/show_bug.cgi?id=146944#c4 and attachment 177914 [details] I think I better spend my time updating the document I mentioned in bug https://bugs.documentfoundation.org/show_bug.cgi?id=146958#c2 by information that helps me to get along with the problem. For example this way: (1) The user profile should be under version control. (2) If you happen to see repeating splash screens: (2a) Trying to abort the process using the task manager may not work. You can abort it using the resource monitor. Maybe you need several tries to hit the confirmation button of the resource monitor: Try to hit it in the split second pause between the splash screens. This makes it unnecessary to restart the current session to abort the LO Process. You probably will be asked to send a crash report but this is useless (see Timurs comment https://bugs.documentfoundation.org/show_bug.cgi?id=146943#c1). Time spent on trying to find steps to reproduce is wasted as the crash seem to occur at random for no obvious reason. (2b) Check if the installed extensions still work. If not (that's usually the case), try to reinstall them or restore the damaged parts of the user profile from version control. This is faster than reinstalling the extensions individually. That's one of the reasons for point (1). (2c) Starting the recovery process one more time in general works as usual. You only have to find out what part of your work got lost and to redo it. That's the same as after any common crash which does not ask you to send a crash report. There are other options I did not try yet: (ad 2b) My Windows installation keeps some previous versions of all directories and files. I think this is a Windows default. This feature helped me sometimes to restore contents destroyed by misbehaving applications. Problems of this approach: At the time you notice the problem it may be too late to use this mechanism as the version you need may be gone. Comparing the current version with some previous version by hand is time consuming and error prone. I had not need to use this backup mechanism as I have the user profile under version control as proposed in (1). (ad 2) The cause of the repeating splash screen phenomenon may be some problem in the user profile. Therefore it might help to figure out what options (including keyboard shortcuts, toolbars etc.) had been changed with respect to the defaults, store necessary data and code at some safe place, store some backup of the user profile, deinstall LibreOffice, delete the user profile, reinstall LibreOffice, reinstall all extensions, restore the saved data and code and change all options to the values they had before. Did not try as this is a lot of work, might cause unexpected side effect and it is not clear if it will stop the repeating splash screen phenomenon. As I cannot provide additional useful information I set the bug back to state 'UNCONFIRMED' as you proposed.
*** Bug 146943 has been marked as a duplicate of this bug. ***
*** Bug 146944 has been marked as a duplicate of this bug. ***
(In reply to Albrecht Müller from comment #0) > - On restart after a crash a document recovery screen should appear, not a > infinite loop of splash screens The loop sounds like the process soffice.bin not being terminated after the crash. It likely a process maxing out a single core.. should be visible in the process manager LibreOffice 7.0.4.2 is also rather old. So maybe check 7.2.x.x first?
(In reply to Telesto from comment #5) > The loop sounds like the process soffice.bin not being terminated after the > crash. It likely a process maxing out a single core.. should be visible in > the process manager As I don't know a way reproduce the bug reliably I cannot check this problem but I think I one time saw a lot of soffice.bin processes, most of them in grey. Don't know what this meant – probably they were finished and ready for removal. I suspect that Writer has some memory leak that eats up slowly (hours, you need to work on documents of some minimum size to notice it) physical memory and therefore removing the processes may take time as it requires to free gigabytes of swap files. Probably the soffice.bin process fails at some point and starts a new instance to fix that failure which fails again etc. Just guessing. My first guess was that the problem is related to Base as this component sometimes produces backup files at a similar rate (several files per second until you do something to stop it, I noticed this by the sound of the hard disk) but now I think the two features are two independent problems. > LibreOffice 7.0.4.2 is also rather old. So maybe check 7.2.x.x first? According to my experience substantial improvements in areas I consider important are pretty rare. Therefore I installed some extensions, developed various workarounds and implemented a few UNO based tools myself. Sometimes I encountered bad regressions so I fear my workarounds and tools may cease to work when I switch to a new version. That's why I am somewhat reluctant to update to new versions.
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Albrecht Müller, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Albrecht Müller, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp