https://bugs.documentfoundation.org/show_bug.cgi?id=147127
--- Comment #6 from Patrick Luby <plub...@neooffice.org> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
