Description: If the code hits an assertion failure while you are viewing a slide show in Impress, the process hangs. Personally, I'd say that we shouldn't even try to handle fatal signals on macOS as we don't have the resources (anybody interested) to make sure that it actually works and keeps working. Steps to Reproduce: Build LibreOffice for debugging. Open another virtual desktop. Run LibreOffice from the command line (instdir/LibreOfficeDev.app/Contents/MacOS/soffice) and move its window to that desktop. (Possibly having it on a separate monitor would also work.) Run Xcode and open the (dummy) osx/soffice.xcodeproj project. In LibreOffice, open a presentation and start a slide show. It turns full-screen and takes over that desktop. (This is why you want to have it on a desktop (or monitor) of its own, you won't be able to switch to other windows on the desktop (monitor) where LibreOffice is running a slide show.) Wait a short while. Now and then try to go forward or backward in the slide show. After a while, you will see in the terminal where you started LibreOffice: > Assertion failed: ([theImage size].width == 128 || [theImage size].width == 32), function getCursor, file /Volumes/TML13/lo/macos/vcl/osx/saldata.cxx, line 251. At this time, the process hangs. Attach it in Xcode. Pause it. You will see a stack trace like this: > #0 0x00007fff20316e7e in mach_msg_trap () > #1 0x00007fff203171f0 in mach_msg () > #2 0x00007fff20443bf7 in __CFRunLoopServiceMachPort () > #3 0x00007fff204422ca in __CFRunLoopRun () > #4 0x00007fff204416ce in CFRunLoopRunSpecific () > #5 0x00007fff286c66d0 in RunCurrentEventLoopInMode () > #6 0x00007fff286c64cc in ReceiveNextEventCommon () > #7 0x00007fff286c61ef in _BlockUntilNextEventMatchingListInModeWithFilter () > #8 0x00007fff22c5ede9 in _DPSNextEvent () > #9 0x00007fff22c5d5af in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] () > #10 0x000000012f055e6e in AquaSalInstance::DoYield(bool, bool) at /Volumes/TML13/lo/macos/vcl/osx/salinst.cxx:544 > #11 0x0000000118ed295b in ImplYield(bool, bool) at /Volumes/TML13/lo/macos/vcl/source/app/svapp.cxx:463 > #12 0x0000000118ed25c0 in Application::Yield() at /Volumes/TML13/lo/macos/vcl/source/app/svapp.cxx:528 > #13 0x00000001184b1486 in Dialog::Execute() at /Volumes/TML13/lo/macos/vcl/source/window/dialog.cxx:1053 > #14 0x0000000118e10353 in SalInstanceDialog::run() at /Volumes/TML13/lo/macos/vcl/source/app/salvtables.cxx:1568 > #15 0x0000000111e55bb1 in weld::DialogController::run() at /Volumes/TML13/lo/macos/include/vcl/weld.hxx:2378 > #16 0x00000001121c6903 in (anonymous namespace)::RecoveryUI::impl_doEmergencySave() at /Volumes/TML13/lo/macos/svx/source/unodraw/recoveryui.cxx:257 > #17 0x00000001121c6417 in (anonymous namespace)::RecoveryUI::dispatchWithReturnValue(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) at /Volumes/TML13/lo/macos/svx/source/unodraw/recoveryui.cxx:147 > #18 0x00000001121c6615 in non-virtual thunk to (anonymous namespace)::RecoveryUI::dispatchWithReturnValue(com::sun::star::util::URL const&, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> const&) () > #19 0x000000010b8be34b in desktop::(anonymous namespace)::impl_callRecoveryUI(bool, bool) at /Volumes/TML13/lo/macos/desktop/source/app/app.cxx:985 > #20 0x000000010b8bdd56 in desktop::Desktop::Exception(ExceptionCategory) at /Volumes/TML13/lo/macos/desktop/source/app/app.cxx:1139 > #21 0x0000000118ef72ca in VCLExceptionSignal_impl(void*, oslSignalInfo*) at /Volumes/TML13/lo/macos/vcl/source/app/svmain.cxx:166 > #22 0x000000010b6cf4ae in callSignalHandler(oslSignalInfo*) at /Volumes/TML13/lo/macos/sal/osl/all/signalshared.cxx:59 > #23 0x000000010b75f867 in (anonymous namespace)::signalHandlerFunction(int, __siginfo*, void*) at /Volumes/TML13/lo/macos/sal/osl/unx/signal.cxx:451 > #24 0x00007fff2038fd7d in _sigtramp () > #25 0x00007fff2031d463 in __pthread_kill () > #26 0x00007fff2034b610 in pthread_kill () > #27 0x00007fff2029e720 in abort () > #28 0x00007fff2029d9d6 in __assert_rtn () > #29 0x000000012f035eb4 in SalData::getCursor(PointerStyle) at /Volumes/TML13/lo/macos/vcl/osx/saldata.cxx:251 > #30 0x000000012f043af2 in AquaSalFrame::getCurrentCursor() at /Volumes/TML13/lo/macos/vcl/osx/salframe.cxx:941 > #31 0x000000012f0e79ba in -[SalFrameView resetCursorRects] at /Volumes/TML13/lo/macos/vcl/osx/salframeview.mm:490 Clearly it is the attempt to handle the SIGABRT generated by the assertion failure that hangs the process (VCLExceptionSignal_impl etc), instead of showing some "helpful" information window offering to recover the document or whatever shit it would attempt to do. Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
I will fix that particular assertion failure, sure, but the main problem this bug report is about remains.
Side note: The assert is probably recent introduced; similar issue bug 139493
The assert is from b3d077a9201d10f2243a7e187af93feb9bfd26ff , two years ago. No idea why the assertion failure was not hit earlier.
This is a very old unconfirmed bug :) I guess it still applies Tor? If so, I guess we can just set it as new?
Yeah, I still agree with what I wrote, "we shouldn't even try to handle fatal signals on macOS". (If we do it currently, I don't know.) At leat not until somebody actually has verified that it makes sense to catch them and do whatever we do.