Bug 146626 - Crash in macOS Calc on font size operation on multi-monitor setup
Summary: Crash in macOS Calc on font size operation on multi-monitor setup
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
7.1.8.1 release
Hardware: All macOS (All)
: medium normal
Assignee: Patrick (volunteer)
URL:
Whiteboard: target:7.5.5 target:7.6.0 target:24.2...
Keywords: bibisectRequest, haveBacktrace, regression
Depends on:
Blocks: Multimonitor Crash
  Show dependency treegraph
 
Reported: 2022-01-06 20:45 UTC by Emil Prpic
Modified: 2023-11-21 09:30 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
LibreOffice About (164.54 KB, image/png)
2022-01-06 20:46 UTC, Emil Prpic
Details
document that causes trouble (164.64 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-01-06 20:48 UTC, Emil Prpic
Details
screenshot of crash alert (84.21 KB, image/png)
2022-01-06 20:49 UTC, Emil Prpic
Details
Dialog 1 that appears after Calc crashes (269.16 KB, image/png)
2023-03-19 10:07 UTC, Emil Prpic
Details
Dialog 2 that appear after clicking OK ("U redu" in Croatian) in the Dialog 1 (326.98 KB, image/png)
2023-03-19 10:09 UTC, Emil Prpic
Details
Dialog 3 that appears after clicking "Recover Selected" in Dialog 2 (313.01 KB, image/png)
2023-03-19 10:10 UTC, Emil Prpic
Details
Sample of LibreOffice (zipped) (37.12 KB, application/zip)
2023-04-15 22:20 UTC, Emil Prpic
Details
LLDB backtrace on crash (73.73 KB, text/plain)
2023-05-15 09:07 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Emil Prpic 2022-01-06 20:45:30 UTC
Description:
In the specific document in the attachment, Calc crashes in any worksheet, when any column (with different font sizes in cells, for example, try col. B)  is selected and you try to click on a font size combo box in the standard toolbar.
If you try to change font size by right-clicking on selection and choosing Cells, then changing font size in the Font tab, everything seems OK until trying to save. Clicking on save causes crash again. 

Steps to Reproduce:
1.open document attached
2.for example go to sheet 4.CRIKVENICA_za_uvez 
3.select column B
4.click on font size combo box on the toolbar

Actual Results:
Calc crashes

Expected Results:
Font size selection should appear


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
LibreOffice about window - see screenshot in the attachment.
Comment 1 Emil Prpic 2022-01-06 20:46:11 UTC
Created attachment 177358 [details]
LibreOffice About
Comment 2 Emil Prpic 2022-01-06 20:48:10 UTC
Created attachment 177359 [details]
document that causes trouble
Comment 3 Emil Prpic 2022-01-06 20:49:41 UTC
Created attachment 177360 [details]
screenshot of crash alert
Comment 4 LeroyG 2022-01-07 13:09:21 UTC
No issue seen in:
Version: 7.1.8.1 (x64) / LibreOffice Community
Build ID: e1f30c802c3269a1d052614453f260e49458c82c
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: default; VCL: win
Locale: es-MX (es_ES); UI: en-US
Calc: CL
Comment 5 Aron Budea 2022-01-08 22:08:57 UTC
No crash with LO 7.2.5.2 / macOS Monterey.
Comment 6 Timur 2022-01-11 05:53:36 UTC
User Profile Reset: Yes

Your you really delete / rename your user profile?
Comment 7 Emil Prpic 2022-01-11 08:40:46 UTC
(In reply to Timur from comment #6)
> User Profile Reset: Yes
> 
> Your you really delete / rename your user profile?

You mean did I really delete my user profile? Yes, twice. I also completely removed LibreOffice and installed it again.
Comment 8 psidiumcode 2022-01-12 18:52:37 UTC
I could not reproduce it in ver:

Version: 7.2.5.2 / LibreOffice Community
Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5
CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: b4a281af53efa0c36ee1770e6cf4d800be77a6d2
CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

macOS Catalina
Comment 9 Roman Kuznetsov 2022-01-16 21:10:14 UTC
No repro in Monterey

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: d3308503a8c320b4a1c3f6156a6b7e6a71a5806d
CPU threads: 4; OS: Mac OS X 10.16; UI render: Skia/Metal; VCL: osx
Locale: ru-RU (ru_RU.UTF-8); UI: en-US
Calc: threaded
Comment 10 Buovjaga 2022-12-02 13:03:39 UTC
Does it still crash for you with version 7.4?

Set to NEEDINFO.
Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 11 Emil Prpic 2022-12-04 17:15:42 UTC
Hello!

LibreOffice 7.4.2 on macOS Monterey 12.6 problem still persists.
Comment 12 Telesto 2023-01-16 19:04:36 UTC
(In reply to Emil Prpic from comment #11)
> Hello!
> 
> LibreOffice 7.4.2 on macOS Monterey 12.6 problem still persists.

Would you mind to test 7.4.4. A bunch of macOS specific bug got fixed.
Comment 13 Emil Prpic 2023-01-24 15:22:34 UTC
Just tried, the bug is still here.
Comment 14 eisa01 2023-03-17 18:01:28 UTC
No repro

Does it occur on 7.5? 

Version: 7.5.1.2 (AARCH64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 10; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 15 Emil Prpic 2023-03-18 10:10:21 UTC
(In reply to eisa01 from comment #14)
> No repro
> 
> Does it occur on 7.5? 
> 
> Version: 7.5.1.2 (AARCH64) / LibreOffice Community
> Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
> CPU threads: 10; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
> Locale: en-US (en_US.UTF-8); UI: en-US
> Calc: threaded

Just tried, yes it's still present.
Comment 16 QA Administrators 2023-03-19 03:26:05 UTC Comment hidden (obsolete)
Comment 18 Emil Prpic 2023-03-19 10:06:25 UTC
(In reply to Buovjaga from comment #17)
> Could you get a trace of the crash:
> https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS:
> _How_to_get_debug_information

Actually, I can't. :-) 

The instructions on the link that you gave me say:

When an application crashes, macOS prompts you with a dialog window saying “LibreOffice quit unexpectedly.” and asks you if you want to send a report to Apple. Click on the button labelled “Report…”. 

However, even though I have administrator rights, this dialog doesn't appear. 

I only get what you see in the screenshots attached.
Comment 19 Emil Prpic 2023-03-19 10:07:49 UTC
Created attachment 186066 [details]
Dialog 1 that appears after Calc crashes
Comment 20 Emil Prpic 2023-03-19 10:09:08 UTC
Created attachment 186067 [details]
Dialog 2 that appear after clicking OK ("U redu" in Croatian) in the Dialog 1
Comment 21 Emil Prpic 2023-03-19 10:10:42 UTC
Created attachment 186068 [details]
Dialog 3 that appears after clicking "Recover Selected" in Dialog 2
Comment 22 eisa01 2023-04-01 19:31:22 UTC
I can confirm

Are you using two monitors?

I was testing other bugs so was connected to an external screen

I had the document open on the main screen, it also occur on the secondary screen

Version: 7.5.2.2 (AARCH64) / LibreOffice Community
Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2
CPU threads: 10; OS: Mac OS X 13.3; UI render: default; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 23 Emil Prpic 2023-04-02 10:54:29 UTC
Yes, I'm using an external Apple Thunderbolt Display and it is configured as a primary display (while it is connected).
Comment 24 eisa01 2023-04-02 11:36:02 UTC
Thanks for confirming!

Editing bug summary to reflect the new finding
Comment 25 Patrick (volunteer) 2023-04-14 13:14:32 UTC
(In reply to Emil Prpic from comment #18)
> 
> When an application crashes, macOS prompts you with a dialog window saying
> “LibreOffice quit unexpectedly.” and asks you if you want to send a report
> to Apple. Click on the button labelled “Report…”. 
> 
> However, even though I have administrator rights, this dialog doesn't
> appear. 
> 

There is an alternative way using the "Activity Monitor" application. When the dialog in your "Dialog 1 that appears after Calc crashes" attachment appears, can you use the following steps to obtain a "sample" of LibreOffice?

Below are links with the steps to obtain a sample of LibreOffice. The first link is how to launch Activity Monitor from the Finder. The second link is a section further down on the same webpage with instructions for saving a sample file. It is a bit old, but the instructions are still almost exactly the same on newer version of macOS:

http://thexlab.com/faqs/activitymonitor.html#AM-Basics
http://thexlab.com/faqs/activitymonitor.html#AM-Sample-Process

The one change in newer versions of macOS is that the "Sample Process" toolbar button has moved. Now there is a "..." toolbar button. Click on that button and select "Sample Process" in the popup dialog that appears.

Once you obtain a sample and save it to a file, you can upload the file by clicking on the "Add an attachment" link just above this bug's comments section.
Comment 26 Emil Prpic 2023-04-15 22:20:51 UTC
Created attachment 186696 [details]
Sample of LibreOffice (zipped)

Here. Is this it?
Comment 27 Patrick (volunteer) 2023-04-15 23:22:20 UTC
(In reply to Emil Prpic from comment #26)
> Created attachment 186696 [details]
> Sample of LibreOffice (zipped)
> 
> Here. Is this it?

Yes. That is exactly what I was hoping to see.

Your sample indicates that a native exception is being thrown and that uncaught exception causes the crash. Unfortunately, samples don't tell me what code threw the exception so I will try again and see if I can reproduce this bug in my local debug build. If I can reproduce in a debug build, hopefully I can use the debugger to stop where the exception is thrown.

I will post again when I have some news.
Comment 28 Patrick (volunteer) 2023-04-16 13:36:03 UTC
Unfortunately, I cannot reproduce this bug with neither LibreOffice 7.5.2.2, latest nightly build, nor a local debug build on my Mac Silicon running macOS Monterey 12.6.5.

Maybe it is because I am using a generic monitor connected via HDMI instead of Thunderbolt? Or maybe Apple has fixed something in their latest update? I noticed that macos 12.6.5 and 13.3.1 were released in the last week.
Comment 29 eisa01 2023-04-16 14:19:59 UTC
I was connected to a 27" 2560x1440 HDMI screen when I reproduced it
Comment 30 Alex Thurgood 2023-05-15 09:06:09 UTC
Reproduced crashing behaviour with OP-provided test document.

Got a backtrace from lldb, using 

Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community (master daily build) 
Build ID: 98f766004e29ea35eef6fcf3a4c28696b95f6c90
CPU threads: 8; OS: Mac OS X 13.3.1; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded
Comment 31 Alex Thurgood 2023-05-15 09:07:00 UTC
Created attachment 187286 [details]
LLDB backtrace on crash
Comment 32 Alex Thurgood 2023-05-15 10:04:01 UTC
I can't pinpoint an exact version of when this started to crash, but can reproduce the crash at least back to LO7181.

It certainly didn't crash like this in the 6.x branch.
Comment 33 Patrick (volunteer) 2023-05-16 18:12:20 UTC
(In reply to Alex Thurgood from comment #31)
> Created attachment 187286 [details]
> LLDB backtrace on crash

Thank you for the lldb output. What jumped out of the output was the following messages right before the crash:

2023-05-15 10:59:49.241237+0200 soffice[3817:127564] [default] CGSWindowShmemCreateWithPort failed on port 0
libc++abi: terminating due to uncaught exception of type com::sun::star::uno::RuntimeException

The CGSWindowShmemCreateWithPort() is a very low level macOS function that we cannot call directly.

I am not sure what can be done is this function fails, but maybe worst case is we can catch the C++ com::sun::star::uno::RuntimeException that the failure CGSWindowShmemCreateWithPort() apparently triggers. Not sure if that will work or just leave the application in an unusable state.

I'll doing some web searching is see if any other applications have any insight on how to handle these failures.
Comment 34 Patrick (volunteer) 2023-05-16 23:52:45 UTC
(In reply to Alex Thurgood from comment #31)
> Created attachment 187286 [details]
> LLDB backtrace on crash

OK. After looking at the lldb output closer, I think what is happening is that the LibreOffice source code is throwing a com::sun::star::uno::RuntimeException::RuntimeException unexpectedly and no LibreOffice try/catch block has been setup to catch it.

So now the problem to figure out is which code is throwing this unexpected exception. We can see where it is caught (way too late to recover from), but not where the exception is thrown.

Since you can reproduce this bug in lldb, would you be able to run LibreOffice in lldb but, after it has been launched and you have opened any documents that trigger this bug, press Control-C in lldb to stop execution. Then, enter the following lldb command:

b -n 'com::sun::star::uno::RuntimeException::RuntimeException' -C bt -G 1

Then, when the lldb prompt returns, enter "continue" and try to reproduce the bug.

Here's what should happen: the above lldb command should execute a "bt" in lldb every time a com::sun::star::uno::RuntimeException::RuntimeException instance is created (I am assuming that they only get created when an exception is about to be thrown).

I think you only need to post the last 3 "bt" that lldb outputs. The very last should be the same as the one you already posted and the 2 before might be the ones that give us more info and the cause of the bug.
Comment 35 Patrick (volunteer) 2023-05-16 23:59:24 UTC
(In reply to Patrick Luby from comment #34)
> I think you only need to post the last 3 "bt" that lldb outputs. The very
> last should be the same as the one you already posted and the 2 before might
> be the ones that give us more info and the cause of the bug.

I forgot to mention that there will be a huge number of that type of exception thrown (it is a common occurrence within the LibreOffice code). So if you just post the whole output as an attachment, we just need to remember to ignore most of the file, skip to the end, and work backwards.
Comment 36 Patrick (volunteer) 2023-05-28 19:46:11 UTC
I can now reproduce this crash in both the lastest nightly build and in my libreoffice-7-5 local build using a variation of the steps in the following post:

https://bugs.documentfoundation.org/show_bug.cgi?id=148453#c25

The steps that I use are:

1. Open a lengthy, 100+ page .odt file in Writer that has only plain text in it (I use a document filled with unformatted lorem ipsum text).
2. Change the page style in the first paragraph to Heading 2 or 3.
3. Open the keyboard viewer. Note: if the keyboard viewer is opened before steps 1 or 2, LibreOffice won't crash.
4. Go back to Writer and drag the vertical scrollbar to the end and back to the beginning a few times until LibreOffice crashes.

The next step is to see if I am able to break in a debugger where the exception that triggers this crash occurs.
Comment 37 Emil Prpic 2023-05-28 19:48:52 UTC
Thank you for your time and effort, I really respect that, but I don't see how your experiment in Writer is related to a bug that I descibed happening in Calc?
Comment 38 Patrick (volunteer) 2023-05-28 19:56:27 UTC
(In reply to Emil Prpic from comment #37)
> Thank you for your time and effort, I really respect that, but I don't see
> how your experiment in Writer is related to a bug that I descibed happening
> in Calc?

So far, while my steps are different than yours, they produce an identical crash log: a C++ exception RuntimeException is thrown by the LibreOffice code and no code catches it.

Maybe they are different bugs, but one possibility is that once I find which LibreOffice code is throwing the C++ exception, it will be in code that is common to both Writer and Calc.
Comment 39 Emil Prpic 2023-05-28 19:58:47 UTC
I understand. Thank you for your reply!
Comment 40 Commit Notification 2023-05-28 21:39:00 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/2aad9a890cc414394a404ec10f032e62baa5ea54

Partial fix tdf#146626 Catch uncaught DisposedException

It will be available in 7.5.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 41 Commit Notification 2023-05-28 22:25:09 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1bf7da609848652ad99d9bde844b90d37de80ffa

Partial fix tdf#146626 Catch uncaught DisposedException

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 42 Patrick (volunteer) 2023-05-28 22:31:21 UTC
(In reply to Patrick Luby from comment #38)
> Maybe they are different bugs, but one possibility is that once I find which
> LibreOffice code is throwing the C++ exception, it will be in code that is
> common to both Writer and Calc.

I have committed a fix for the crash in Writer that I described in commit #36 and the fix should be in the next nightly build.

Can anyone who can reproduce the Calc crash try out the next nightly build and see if the Calc crash still occurs? I ask because the fix for the crash in Writer was in LibreOffice's macOS accessibility handling code which is common to both Writer and Calc.
Comment 43 Emil Prpic 2023-05-30 09:22:47 UTC
Downloaded LibreOfficeDev_7.5.5.0.0_MacOS_x86-64.dmg from daily builds link, installed it (copied app from DMG to Applications), started and confirmed all security prompts. Opened the same ODS document uploaded here and I can confirm that the problem is still present.
Comment 44 Patrick (volunteer) 2023-06-15 20:07:22 UTC
I am finally able to reproduce this crash even without an external monitor. I am using the latest "master" branch code compiled locally:

Version: 24.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 6e2c8f3f56ab52dfaa9bdce37423bac44cc64061
CPU threads: 8; OS: Mac OS X 12.6.6; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

The key for me was I enabled the Rectangle application which, like the macOS Keyboard Viewer, uses macOS accessibility to communicate with LibreOffice.

I'll post an update when I have more news.
Comment 45 Patrick (volunteer) 2023-06-15 20:12:04 UTC
I forgot to post the stack trace of where the unexpected exception is thrown that causes the crash:

(lldb)  bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.5
  * frame #0: 0x000000010b49fdb8 libsvxlo.dylib`com::sun::star::lang::IndexOutOfBoundsException::IndexOutOfBoundsException(this=0x000000010e692b70, Message_=0x000000016fdf8e10, Context_=0x000000034f8df628) at IndexOutOfBoundsException.hpp:31:29
    frame #1: 0x000000010b498818 libsvxlo.dylib`com::sun::star::lang::IndexOutOfBoundsException::IndexOutOfBoundsException(this=0x000000010e692b70, Message_=0x000000016fdf8e10, Context_=0x000000034f8df628) at IndexOutOfBoundsException.hpp:36:1
    frame #2: 0x000000010b4b3d58 libsvxlo.dylib`accessibility::AccessibleTextHelper_Impl::getAccessibleChild(this=0x000000034f8df5f0, i=1) at AccessibleTextHelper.cxx:1444:19
    frame #3: 0x000000010b4b5554 libsvxlo.dylib`accessibility::AccessibleTextHelper::GetChild(this=0x0000600008067c90, i=1) at AccessibleTextHelper.cxx:1723:54
    frame #4: 0x00000002f8466030 libsclo.dylib`ScAccessibleEditObject::getAccessibleChild(this=0x00000002dc5436f0, nIndex=1) at AccessibleEditObject.cxx:262:26
    frame #5: 0x00000001020b7aac libcomphelper.dylib`comphelper::OAccessibleContextWrapperHelper::baseGetAccessibleChild(this=0x0000600003be90a0, i=1) at accessiblewrapper.cxx:400:65
    frame #6: 0x00000001020b8dbc libcomphelper.dylib`comphelper::OAccessibleContextWrapper::getAccessibleChild(this=0x0000600003be90a0, i=1) at accessiblewrapper.cxx:505:16
    frame #7: 0x00000001140d5d64 libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9298) at a11ywrapper.mm:1067:90
    frame #8: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9478) at a11ywrapper.mm:1069:71
    frame #9: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9658) at a11ywrapper.mm:1069:71
    frame #10: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9838) at a11ywrapper.mm:1069:71
    frame #11: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9a18) at a11ywrapper.mm:1069:71
    frame #12: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9bf8) at a11ywrapper.mm:1069:71
    frame #13: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9dd8) at a11ywrapper.mm:1069:71
    frame #14: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdf9fb8) at a11ywrapper.mm:1069:71
    frame #15: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdfa198) at a11ywrapper.mm:1069:71
    frame #16: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdfa378) at a11ywrapper.mm:1069:71
    frame #17: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdfa558) at a11ywrapper.mm:1069:71
    frame #18: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x000000016fdfa738) at a11ywrapper.mm:1069:71
    frame #19: 0x00000001140d5eec libvclplug_osxlo.dylib`hitTestRunner(point=(X = 365, Y = 152), rxAccessibleContext=0x0000600002d21510) at a11ywrapper.mm:1069:71
    frame #20: 0x00000001140d57a0 libvclplug_osxlo.dylib`-[AquaA11yWrapper accessibilityHitTest:](self=0x0000600002d21500, _cmd="accessibilityHitTest:", point=(x = 365.63671875, y = 829.2578125)) at a11ywrapper.mm:1128:20
    frame #21: 0x00000001140f8e7c libvclplug_osxlo.dylib`-[SalFrameView accessibilityHitTest:](self=0x000000016bb6d7d0, _cmd="accessibilityHitTest:", aPoint=(x = 365.63671875, y = 829.2578125)) at salframeview.mm:2460:16
    frame #22: 0x00000001a06187f0 AppKit`-[NSWindow(NSWindowAccessibility) accessibilityHitTest:] + 420
    frame #23: 0x00000001a0191a4c AppKit`-[NSApplication(NSApplicationAccessibility) accessibilityHitTest:] + 292
    frame #24: 0x00000001a015f11c AppKit`CopyElementAtPosition + 160
    frame #25: 0x00000001a2df2340 HIServices`_AXXMIGCopyElementAtPosition + 364
    frame #26: 0x00000001a2e16e28 HIServices`_XCopyElementAtPosition + 356
    frame #27: 0x00000001a2dcfd50 HIServices`mshMIGPerform + 204
    frame #28: 0x000000019d1f97e8 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 60
    frame #29: 0x000000019d1f96a4 CoreFoundation`__CFRunLoopDoSource1 + 604
    frame #30: 0x000000019d1f7b38 CoreFoundation`__CFRunLoopRun + 2372
    frame #31: 0x000000019d1f6a54 CoreFoundation`CFRunLoopRunSpecific + 600
    frame #32: 0x00000001a5e3b338 HIToolbox`RunCurrentEventLoopInMode + 292
    frame #33: 0x00000001a5e3b0b4 HIToolbox`ReceiveNextEventCommon + 564
    frame #34: 0x00000001a5e3ae68 HIToolbox`_BlockUntilNextEventMatchingListInModeWithFilter + 72
    frame #35: 0x000000019fd5f4b8 AppKit`_DPSNextEvent + 860
    frame #36: 0x000000019fd5ddb0 AppKit`-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1328
    frame #37: 0x000000011405b4f0 libvclplug_osxlo.dylib`AquaSalInstance::DoYield(this=0x0000000103738680, bWait=true, bHandleAllCurrentEvents=false) at salinst.cxx:595:22
    frame #38: 0x00000001172f8a30 libvcllo.dylib`ImplYield(i_bWait=true, i_bAllEvents=false) at svapp.cxx:369:48
    frame #39: 0x00000001172f83a0 libvcllo.dylib`Application::Yield() at svapp.cxx:453:5
    frame #40: 0x00000001172f8184 libvcllo.dylib`Application::Execute() at svapp.cxx:347:13
    frame #41: 0x0000000100df5958 libsofficeapp.dylib`desktop::Desktop::Main(this=0x000000016fdff558) at app.cxx:1592:13
    frame #42: 0x000000011731ebbc libvcllo.dylib`ImplSVMain() at svmain.cxx:204:35
    frame #43: 0x000000011405a8b8 libvclplug_osxlo.dylib`AquaSalInstance::handleAppDefinedEvent(pEvent=0x000060000370d440) at salinst.cxx:448:20
    frame #44: 0x00000001140fd4a4 libvclplug_osxlo.dylib`-[VCL_NSApplication sendEvent:](self=0x000000010e6054a0, _cmd="sendEvent:", pEvent=0x000060000370d440) at vclnsapp.mm:92:9
    frame #45: 0x00000001a0188090 AppKit`-[NSApplication _handleEvent:] + 76
    frame #46: 0x000000019fd4ffa4 AppKit`-[NSApplication run] + 636
    frame #47: 0x000000019fd21698 AppKit`NSApplicationMain + 1132
    frame #48: 0x000000011405f230 libvclplug_osxlo.dylib`AquaSalInstance::SVMainHook(this=0x0000000103738680, pnInit=0x000000016fdff4a8) at salinst.cxx:1051:5
    frame #49: 0x000000011731eb7c libvcllo.dylib`ImplSVMain() at svmain.cxx:197:54
    frame #50: 0x0000000117320358 libvcllo.dylib`SVMain() at svmain.cxx:236:12
    frame #51: 0x0000000100e7bf98 libsofficeapp.dylib`soffice_main at sofficemain.cxx:94:12
    frame #52: 0x0000000100003f44 soffice`sal_main at main.c:51:15
    frame #53: 0x0000000100003f1c soffice`main(argc=1, argv=0x000000016fdff7d8) at main.c:49:1
    frame #54: 0x000000010001908c dyld`start + 520
libc++abi: terminating with uncaught exception of type com::sun::star::lang::IndexOutOfBoundsException
Comment 46 Commit Notification 2023-06-16 16:39:05 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/b6299c9e56f70ebc124814f4001e149e7be298ad

tdf#146626 catch IndexOutOfBoundsException when fetching accessible children

It will be available in 24.2.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 47 Patrick (volunteer) 2023-06-17 17:18:54 UTC
My fix is now in the nightly build:

https://dev-builds.libreoffice.org/daily/master/current.html

I tested the 2023-06-17 Silicon Mac build (the first nightly build with his fix) and LibreOffice no longer crashes for me when I have the Rectangle application running and I do the steps in comment #0.

Marking this bug as Resolved/Fixed. Can anyone verify that the bug is fixed for you or if there are any hangs and/or crashes that we still have not fixed?
Comment 48 Patrick (volunteer) 2023-06-20 17:26:59 UTC
Nightly builds for Mac Intel that include the fix are now available:

https://dev-builds.libreoffice.org/daily/master/current.html
Comment 49 Commit Notification 2023-06-20 18:01:09 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/b1dd43d64d41ebed8b8b92c9b32ea1e47dbdfa65

tdf#146626 catch IndexOutOfBoundsException when fetching accessible children

It will be available in 7.6.0.0.beta2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 50 gaelers 2023-11-21 08:55:24 UTC Comment hidden (spam)