Bug 139535 - Attempt at handling fatal signal on macOS causes a hang at least while viewing a slide show
Summary: Attempt at handling fatal signal on macOS causes a hang at least while viewin...
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-01-11 10:21 UTC by Tor Lillqvist
Modified: 2021-01-11 12:12 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tor Lillqvist 2021-01-11 10:21:23 UTC
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:
.
Comment 1 Tor Lillqvist 2021-01-11 10:22:08 UTC
I will fix that particular assertion failure, sure, but the main problem this bug report is about remains.
Comment 2 Telesto 2021-01-11 11:54:40 UTC
Side note: The assert is probably recent introduced; similar issue bug 139493
Comment 3 Tor Lillqvist 2021-01-11 12:12:35 UTC
The assert is from b3d077a9201d10f2243a7e187af93feb9bfd26ff , two years ago. No idea why the assertion failure was not hit earlier.