Summary: | CRASH - editing/saving of file in LibreOffice exceeds allowed system disk write cache maximum leading to exception crash Apple M1 | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Alex Thurgood <iplaw67> |
Component: | LibreOffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | major | CC: | guibomacdev, telesto |
Priority: | high | ||
Version: | 7.2.5.2 release | ||
Hardware: | ARM | ||
OS: | macOS (All) | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=148221 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Attachments: | Diagnostic report produced by macOS |
Description
Alex Thurgood
2022-02-02 11:33:07 UTC
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. |