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.
Created attachment 177358 [details] LibreOffice About
Created attachment 177359 [details] document that causes trouble
Created attachment 177360 [details] screenshot of crash alert
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
No crash with LO 7.2.5.2 / macOS Monterey.
User Profile Reset: Yes Your you really delete / rename your user profile?
(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.
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
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
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.
Hello! LibreOffice 7.4.2 on macOS Monterey 12.6 problem still persists.
(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.
Just tried, the bug is still here.
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
(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.
[Automated Action] NeedInfo-To-Unconfirmed
Could you get a trace of the crash: https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS:_How_to_get_debug_information
(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.
Created attachment 186066 [details] Dialog 1 that appears after Calc crashes
Created attachment 186067 [details] Dialog 2 that appear after clicking OK ("U redu" in Croatian) in the Dialog 1
Created attachment 186068 [details] Dialog 3 that appears after clicking "Recover Selected" in Dialog 2
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
Yes, I'm using an external Apple Thunderbolt Display and it is configured as a primary display (while it is connected).
Thanks for confirming! Editing bug summary to reflect the new finding
(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.
Created attachment 186696 [details] Sample of LibreOffice (zipped) Here. Is this it?
(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.
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.
I was connected to a 27" 2560x1440 HDMI screen when I reproduced it
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
Created attachment 187286 [details] LLDB backtrace on crash
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.
(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.
(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.
(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.
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.
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?
(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.
I understand. Thank you for your reply!
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.
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.
(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.
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.
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.
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
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.
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?
Nightly builds for Mac Intel that include the fix are now available: https://dev-builds.libreoffice.org/daily/master/current.html
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.
Koopa Troopas in Super Mario 64: Green, turtle-like enemies that can be defeated by jumping on them or throwing them. Link: https://supermario64.io