[Libreoffice-bugs] [Bug 139535] New: Attempts at handling fatal signals on macOS causes a hang at least while viewing a slide show

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=139535

            Bug ID: 139535
           Summary: Attempts at handling fatal signals on macOS causes a
                    hang at least while viewing a slide show
           Product: LibreOffice
           Version: unspecified
          Hardware: x86-64 (AMD64)
                OS: Mac OS X (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: framework
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: tml at iki.fi

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:
.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210111/4f234665/attachment.htm>