Description: LibreOffice isn't compiled to reduce disk writes on SSD drives, which equip all current Macs. This leads to situations, when making multiple edits and saves in a large file to a situation in which the builtin macOS disk write protection system is exceeded, generating an exception that LibreOffice doesn't know how to handle, which in turn leads to a crash. In my case, I believe (from the trace) that the diagnostic report that macOS generated occurred when editing a Draw file with multiple pages of drawings, each page containing one or more relatively complex SVG files. However, this could also occur when editing a heavy Writer file, or any other multiple edit/save operations on the file. MacOS fixes a limit on the number of disk writes in a 24 hour period per application, in order to limit wear on SSD drives. The LibreOffice app bundle doesn't seem to include any code which handles that situation gracefully, leading to the crash and the diagnostic report. Steps to Reproduce: 1. In a SSD equipped Mac device, open a large file, or several large files, for editing. 2. Make multiple saves to the files. 3. Repeat edits and saves over a short period of time (although 24 hours is the limit set by macOS, the SSD write buffer can be exceeded in much less time) Actual Results: CRASH due to unhandled exception generated by excessive write operations on SSD Expected Results: No crash, correct disk write management in accordance with Apple guidelines: https://developer.apple.com/documentation/xcode/reducing-disk-writes Reproducible: Sometimes User Profile Reset: Yes Additional Info: The software should manage disk writes in accordance with macOS programming guidelines.
Created attachment 177988 [details] Diagnostic report produced by macOS
I would be inclined to mark this as critical, as it seems to me that using LibreOffice will either lead to increased wear of the SSD or else intempestuous crashes - either way, data longevity is compromised.
For the record, the machine is a Macbook Pro M1 with 16Gb RAM.
Would this still be the case? To replicate I would have to get 2 GB of writes if I read the diagnostic report correctly?
Assuming the crash still occurs with recent buids, are you able to get a crash log when it finally crashes. I don't know how we'd get around Apple's arbitrary limits, but maybe we can catch the error and handle it with a error dialog instead of crashing.
(In reply to Patrick Luby from comment #5) > Assuming the crash still occurs with recent buids, are you able to get a > crash log when it finally crashes. I don't know how we'd get around Apple's > arbitrary limits, but maybe we can catch the error and handle it with a > error dialog instead of crashing. To clarify, I am hoping for a crash log from a recent nightly build. The problem with your diagnostic log as that I don't see a crash. Instead, I only see several different threads with the following at the bottom of their stack trace: 2 osl_writeFile + 99 (libuno_sal.dylib.3 + 185491) [0x10d4c9493] 2 ??? [0x7ff897a56940] osl_writeFile() does a little bounds checking and then invokes macOS' C write() function (the second function has no matching library name so that tells me it is an OS function). I assume that the threads stuck in "??? [0x7ff897a56940]" indicates that macOS is blocking that thread until it finishes coordinating all of the pending writing of bytes to disk (writing to disk is slow). In other words, your diagnostic indicates that LibreOffice is not doing anything but merely waiting on macOS to return control to LibreOffice. That's why I want to see the actual crash stack trace: to determine whose code is actually crashing.
(In reply to Patrick Luby from comment #6) Hi Patrick, Thanks for starting to look at this, but I have not been able to reproduce this in a while, so we might as well mark it WFM. As this problem occurred at work, I have since avoided trying to encounter the same situation again by not importing complex SVG images in my Draw files, and then editing them with annotations. I have reverted to using PNG or TIFF files instead, so the number of objects that the application has to manage in memory is reduced. Reproduction inevitably takes quite a good deal of time to reproduce, as one of the constraints seems to be the size of the imported SVG files and the number of edits (whether by altering paths, grouping, changing formatting attributes, whatever) carried out on them. As Draw has been inherently more unstable for me on macOS since the move to 5.x, and I've had my fingers burned too many times, I've taken to saving often, even after a series of minor edits. Perhaps this is also a contributing factor (I would imagine so, since there is a specific write request to disk). Like I said, I haven't encountered the issue again recently, but I've changed my habits to save me time, frustration and avoid data loss.