Bug 164072 - LibreOffice crashes when deleting all comments (debug)
Summary: LibreOffice crashes when deleting all comments (debug)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.3.2 release
Hardware: All All
: medium normal
Assignee: Michael Weghorn
URL:
Whiteboard: target:25.8.0 target:25.2.0.0.beta2 t...
Keywords: bibisectRequest, haveBacktrace
: 164801 (view as bug list)
Depends on:
Blocks: Writer-Comments
  Show dependency treegraph
 
Reported: 2024-11-27 15:17 UTC by qa-admin@libreoffice.org
Modified: 2025-02-05 22:25 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
File contains two words and two comments to illustrate the crash (9.42 KB, application/vnd.oasis.opendocument.text)
2024-11-27 15:43 UTC, qa-admin@libreoffice.org
Details
bt (12.19 KB, text/plain)
2024-12-06 15:21 UTC, Julien Nabet
Details
Backtrace from debug build (14.31 KB, text/plain)
2025-01-30 16:35 UTC, Buovjaga
Details

Note You need to log in before you can comment on or make changes to this bug.
Description qa-admin@libreoffice.org 2024-11-27 15:17:52 UTC
I have basically the same issue as described in Bug ID 120222. I apologize if it was incorrect not to comment in the thread for this Bug ID.

I am running the following version:

Version: 24.8.3.2 (AARCH64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 8; OS: macOS 14.4; UI render: Skia/Metal; VCL: osx
Locale: de-DE (de_DE.UTF-8); UI: en-US
Calc: threaded

The problem can be produced as follows:
1) Create a new document in Writer
2) Write at least two characters
3) Add one comment to each character
4) Attempt to "delete all comments" or "delete all comments by"

=> LibreOffice crashes completely and immediately

The issue also occurs in safe mode for me and with completely new documents that contain no content at all.

Thank you in advance for your help!!
Comment 1 Xisco Faulí 2024-11-27 15:29:36 UTC
I can't reproduce it in

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7a7ba9cbee91485a9254949d1594352b3629c070
CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3
Locale: es-ES (es_ES.UTF-8); UI: en-US
Calc: threaded

Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 2 Xisco Faulí 2024-11-27 15:30:27 UTC
Maybe MacOS only ?
Comment 3 qa-admin@libreoffice.org 2024-11-27 15:43:45 UTC
Created attachment 197826 [details]
File contains two words and two comments to illustrate the crash
Comment 4 qa-admin@libreoffice.org 2024-11-27 15:44:40 UTC
(In reply to Xisco Faulí from comment #2)
> Maybe MacOS only ?

This is possible. I am unsure how to find the crash report and upload it here on macOS. LibreOffice does not automatically generate a report.
Comment 5 Patrick (volunteer) 2024-11-27 16:06:11 UTC
I cannot reproduce this bug. I see no crash when I select the Edit > Comment > Delete All Comments or Delete All Comments by Author menu items:

Version: 24.8.3.2 (AARCH64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Metal; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded
Comment 6 qa-admin@libreoffice.org 2024-11-27 16:11:57 UTC
(In reply to Patrick (volunteer) from comment #5)
> I cannot reproduce this bug. I see no crash when I select the Edit > Comment
> > Delete All Comments or Delete All Comments by Author menu items:
> 
> Version: 24.8.3.2 (AARCH64) / LibreOffice Community
> Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
> CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Metal; VCL: osx
> Locale: en-CA (en_CA.UTF-8); UI: en-US
> Calc: threaded

Very interesting! Can you try to right-click on a comment and select "delete all comments" from there? I will check whether "Edit > Comment
> > Delete All Comments" works for me.
Comment 7 Patrick (volunteer) 2024-11-27 16:37:06 UTC
(In reply to rjnonym from comment #6)
> Very interesting! Can you try to right-click on a comment and select "delete
> all comments" from there? I will check whether "Edit > Comment
> > > Delete All Comments" works for me.

No crash with either popup menu item.

Does the crash still occur if you restart LibreOffice in safe mode by selecting the Help > Restart in Safe Mode menu item?
Comment 8 Julien Nabet 2024-11-27 21:56:08 UTC
Rjnonym: if you still reproduce this in safe mode (as Patrick suggested), would it be possible you follow https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS:_How_to_get_debug_information to provide extra info?
Comment 9 qa-admin@libreoffice.org 2024-11-27 22:09:06 UTC
(In reply to Patrick (volunteer) from comment #7)
> (In reply to rjnonym from comment #6)
> > Very interesting! Can you try to right-click on a comment and select "delete
> > all comments" from there? I will check whether "Edit > Comment
> > > > Delete All Comments" works for me.
> 
> No crash with either popup menu item.
> 
> Does the crash still occur if you restart LibreOffice in safe mode by
> selecting the Help > Restart in Safe Mode menu item?

So, I was able to further research this. 

1) The crash does NOT occur when I use Edit > Comment > Delete All Comments. This could explain why the issue is not widely known, if it affects many installations at all. I apologize for not checking this earlier.

2) The crash occurs ONLY when right-clicking on the comment in the sidebar and selecting Delete All Comments (by Author) in the context menu. 

3) This context-menu crash occurs both in normal and in safe mode.
Comment 10 QA Administrators 2024-11-28 03:13:15 UTC Comment hidden (obsolete)
Comment 11 Sirlaed 2024-11-28 13:54:45 UTC
I tried it on windows, but doesn't crash either

Version: 24.8.3.2 (X86_64) / LibreOffice Community
Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win
Locale: es-CO (es_CO); UI: es-ES
Calc: CL threaded
Comment 12 Sirlaed 2024-11-28 13:56:11 UTC
(In reply to Sirlaed from comment #11)
> I tried it on windows, but doesn't crash neither
> 
> Version: 24.8.3.2 (X86_64) / LibreOffice Community
> Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92
> CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render:
> Skia/Vulkan; VCL: win
> Locale: es-CO (es_CO); UI: es-ES
> Calc: CL threaded
Comment 13 Aryeh 2024-12-01 16:32:29 UTC
(In reply to rjnonym from comment #9)
> So, I was able to further research this. 
> 
> 1) The crash does NOT occur when I use Edit > Comment > Delete All Comments.
> This could explain why the issue is not widely known, if it affects many
> installations at all. I apologize for not checking this earlier.
> 
> 2) The crash occurs ONLY when right-clicking on the comment in the sidebar
> and selecting Delete All Comments (by Author) in the context menu. 
> 
> 3) This context-menu crash occurs both in normal and in safe mode.

I tried both #1 and #2 and was not able to reproduce the crash.

Version: 24.8.2.1 (AARCH64) / LibreOffice Community
Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13
CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 14 Buovjaga 2024-12-03 06:27:07 UTC
(In reply to rjnonym from comment #9)
> 2) The crash occurs ONLY when right-clicking on the comment in the sidebar
> and selecting Delete All Comments (by Author) in the context menu. 

No crash for me.

Arch Linux 64-bit
Version: 24.8.3.2 (X86_64) / LibreOffice Community
Build ID: 480(Build:2)
CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
24.8.3-1
Calc: threaded
Comment 15 Julien Nabet 2024-12-06 15:21:32 UTC
Created attachment 197984 [details]
bt

On pc Debian x86-64 with master sources updated today, I could reproduce this with gen rendering (not with gtk3 rendering).
Comment 16 Julien Nabet 2024-12-06 15:28:35 UTC
I noticed this on console:
warn:legacy.osl:563630:563630:vcl/source/window/window.cxx:307: Window ( 10MenuButton()) with live SystemWindows destroyed:  18MenuFloatingWindow()
Window ( 10MenuButton()) with live SystemWindows destroyed:  18MenuFloatingWindow()
Comment 17 Michael Weghorn 2024-12-10 07:53:07 UTC
(In reply to Julien Nabet from comment #16)
> I noticed this on console:
> warn:legacy.osl:563630:563630:vcl/source/window/window.cxx:307: Window (
> 10MenuButton()) with live SystemWindows destroyed:  18MenuFloatingWindow()
> Window ( 10MenuButton()) with live SystemWindows destroyed: 
> 18MenuFloatingWindow()

IIUC, this (and the related crash with the backtrace in comment 15) is unrelated to the original problem reported here and should be fixed by https://gerrit.libreoffice.org/c/core/+/178197 .
Comment 18 Commit Notification 2024-12-10 08:46:38 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/90d9b6e12f0aa9a569958586832bd4abe9561197

tdf#164072 vcl: Let MenuButton dispose its PopupMenu

It will be available in 25.8.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 19 Commit Notification 2024-12-10 09:50:47 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-25-2":

https://git.libreoffice.org/core/commit/9351d4d6a131b7e4c05a5762ef74789d37054aa3

tdf#164072 vcl: Let MenuButton dispose its PopupMenu

It will be available in 25.2.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 20 qa-admin@libreoffice.org 2024-12-26 09:54:40 UTC Comment hidden (spam)
Comment 21 qa-admin@libreoffice.org 2024-12-26 09:59:12 UTC Comment hidden (spam)
Comment 22 Buovjaga 2025-01-23 05:19:04 UTC
*** Bug 164801 has been marked as a duplicate of this bug. ***
Comment 23 Heiko Tietze 2025-01-23 05:48:03 UTC
Mentioned on the duplicate that it crashes when the command is run via context menu on the comments bar but not via the menu bar. Highly important/severe since affecting 25.2.
Comment 24 Xisco Faulí 2025-01-23 09:31:06 UTC
(In reply to Heiko Tietze from comment #23)
> Mentioned on the duplicate that it crashes when the command is run via
> context menu on the comments bar but not via the menu bar. Highly
> important/severe since affecting 25.2.

About information is missing, please provide it. OTOH, have you tried with GEN environment ?
Comment 25 Xisco Faulí 2025-01-30 15:11:04 UTC
Not reproducible in

Version: 24.8.4.2 (X86_64) / LibreOffice Community
Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002
CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US
Calc: threaded
Comment 26 Buovjaga 2025-01-30 15:14:30 UTC
I repro with a debug build, but not otherwise. kf5, kf6, gen, NOT gtk3.

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: bebadddfb999f678a44cdc486dfd91f38e563c9f
CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Comment 27 Michael Weghorn 2025-01-30 15:36:16 UTC
(In reply to Buovjaga from comment #26)
> I repro with a debug build, but not otherwise. kf5, kf6, gen, NOT gtk3.
> 
> Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: bebadddfb999f678a44cdc486dfd91f38e563c9f
> CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland)
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: CL threaded

I can NOT reproduce with gen/kf5/qt6 and local debug build.

Do you have a backtrace?

tdf#164801 at first glance looks like the (debug-build only) crash/assert that is meant to be fixed by the commit in comment 18 (which IIUC, is different what this ticket originally for macOS and presumably a release build used to be about).

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5d2b2b9f381bbfb19ffd393f361c1fdd4a898550
CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: x11
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5d2b2b9f381bbfb19ffd393f361c1fdd4a898550
CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5d2b2b9f381bbfb19ffd393f361c1fdd4a898550
CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland)
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: CL threaded
Comment 28 Heiko Tietze 2025-01-30 15:43:50 UTC
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7f4901ded76fa3f3dffaef2d8f68d5c4803d98a2
CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+xcb)
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

console message:

warn:legacy.osl:349765:349765:vcl/source/window/window.cxx:307: Window ( N2sw10annotation15SwAnnotationWinE()) with live SystemWindows destroyed:  18MenuFloatingWindow()
Window ( N2sw10annotation15SwAnnotationWinE()) with live SystemWindows destroyed:  18MenuFloatingWindow()
warn:vcl:349765:349765:vcl/source/control/prgsbar.cxx:175: StatusBar::SetProgressValue(): nPercent > 100

Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by Noel in https://gerrit.libreoffice.org/c/core/+/179445
Comment 29 Buovjaga 2025-01-30 16:35:17 UTC
Created attachment 198892 [details]
Backtrace from debug build
Comment 30 Noel Grandin 2025-01-31 13:12:38 UTC
(In reply to Heiko Tietze from comment #28)
> Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by
> Noel in https://gerrit.libreoffice.org/c/core/+/179445

How did you figure that? Because if I build with the commit before my changes, it still crashes in the same way.
Comment 31 Heiko Tietze 2025-01-31 13:21:08 UTC
(In reply to Noel Grandin from comment #30)
> (In reply to Heiko Tietze from comment #28)
> > Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by
> > Noel in https://gerrit.libreoffice.org/c/core/+/179445
> 
> How did you figure that? Because if I build with the commit before my
> changes, it still crashes in the same way.

Quickly skimmed over the lines and commits, and yours turning SwSidebarItem into SwAnnotationItem is the latest. Good if not, bibisection has been requested.
Comment 32 Buovjaga 2025-01-31 13:53:17 UTC
(In reply to Heiko Tietze from comment #31)
> (In reply to Noel Grandin from comment #30)
> > (In reply to Heiko Tietze from comment #28)
> > > Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by
> > > Noel in https://gerrit.libreoffice.org/c/core/+/179445
> > 
> > How did you figure that? Because if I build with the commit before my
> > changes, it still crashes in the same way.
> 
> Quickly skimmed over the lines and commits, and yours turning SwSidebarItem
> into SwAnnotationItem is the latest. Good if not, bibisection has been
> requested.

Can't be done with our binaries, would need to compile at each step.
Comment 33 Noel Grandin 2025-01-31 15:54:04 UTC
This appears to have started with

   commit 6708246e20ce522e673f539369cd38687d2dd16d
   Author: Michael Weghorn <m.weghorn@posteo.de>
   Date:   Thu Dec 5 11:06:48 2024 +0000
   tdf#164093 tdf#157001 a11y: Improve menu window disposal
Comment 34 Michael Weghorn 2025-01-31 16:04:31 UTC
(In reply to Noel Grandin from comment #33)
> This appears to have started with
> 
>    commit 6708246e20ce522e673f539369cd38687d2dd16d
>    Author: Michael Weghorn <m.weghorn@posteo.de>
>    Date:   Thu Dec 5 11:06:48 2024 +0000
>    tdf#164093 tdf#157001 a11y: Improve menu window disposal

    commit 9351d4d6a131b7e4c05a5762ef74789d37054aa3
    Author: Michael Weghorn <m.weghorn@posteo.de>
    Date:   Tue Dec 10 08:31:24 2024 +0100

        tdf#164072 vcl: Let MenuButton dispose its PopupMenu

is supposed to fix the issue observable since that commit and does in my setup. Since I can't reproduce the remaining issue myself, it's hard to tell what's going wrong.
Comment 35 Michael Weghorn 2025-01-31 17:41:52 UTC
(In reply to Michael Weghorn from comment #34)
> Since I can't reproduce the remaining issue myself, it's hard to tell
> what's going wrong.

OK, I can reproduce now when I right-click on a comment area in order to open the menu (as described in tdf#164801). (Previously, I was left-clicking the "small triangle" on a comment to open the menu, in which case the assert doesn't get triggered.

Will take a look, but might only really get to it sometime after FOSDEM.
Comment 36 Noel Grandin 2025-02-01 06:17:15 UTC
Michael, in this specific case, I don't think this assert is telling us anything useful. So it may be worth simply making that assert a little more complex and excluding the case of popup menu objects.
Comment 37 Michael Weghorn 2025-02-04 12:54:53 UTC
(In reply to Noel Grandin from comment #36)
> Michael, in this specific case, I don't think this assert is telling us
> anything useful. So it may be worth simply making that assert a little more
> complex and excluding the case of popup menu objects.

Thanks, Noel.
Disposing a child window before its parent doesn't seem ideal to me at first sight, so I've submitted a change with an approach that avoids that:
https://gerrit.libreoffice.org/c/core/+/181110
Comment 38 Michael Weghorn 2025-02-04 13:02:37 UTC
(In reply to Michael Weghorn from comment #37)
> Disposing a child window before its parent doesn't seem ideal to me at first
> sight, (...)

That was meant to be the other way around: "Disposing a parent window before its child doesn't seem ideal to me (...)."
Comment 39 Commit Notification 2025-02-04 18:12:22 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0467f88e2892b36d6f89b626f0d273fa8c403a87

tdf#164072 sw annotation: Use menu parent that outlives menu

It will be available in 25.8.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 40 Buovjaga 2025-02-04 19:43:26 UTC
No crash anymore

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a49021db6b5ee9afd9d72a3f20f2fb5579838e3e
CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: CL threaded
Comment 41 Michael Weghorn 2025-02-05 08:35:24 UTC
While the commit from comment 39 was primarily targeted at the assert in debug builds discussed earlier, I also cannot reproduce any crash on macOS with current master.

It may be that the crash there was caused by the same underlying issue (menu parent disposed while menu is still used).

When I revert the commit from comment 39 locally and comment the assert, I can still reproduce another crash with the following backtrace on macOS:

1 rtl::Reference<vcl::Window>::get() const ref.hxx 205 0x111e505f0 
2 VclPtr<vcl::Window>::operator bool() const vclptr.hxx 187 0x111e6f2c8 
3 vcl::Window::GetWindowExtentsRelative(vcl::Window const&) const window.cxx 2929 0x112171cd8 
4 MenuFloatingWindow::doShutdown() menufloatingwindow.cxx 103 0x1120ab678 
5 PopupMenu::FinishRun(VclPtr<MenuFloatingWindow> const&, VclPtr<vcl::Window> const&, bool, bool) menu.cxx 3106 0x1120992bc 
6 PopupMenu::ImplExecute(VclPtr<vcl::Window> const&, tools::Rectangle const&, FloatWinPopupFlags, Menu *, bool) menu.cxx 3033 0x11209840c 
7 PopupMenu::Execute(vcl::Window *, tools::Rectangle const&, PopupMenuFlags) menu.cxx 2860 0x112097198 
8 VCLXMenu::execute(com::sun::star::uno::Reference<com::sun::star::awt::XWindowPeer> const&, com::sun::star::awt::Rectangle const&, short) vclxmenu.cxx 509 0x108864e4c 
9 SfxDispatcher::ExecutePopup(rtl::OUString const&, vcl::Window *, Point const *) dispatch.cxx 1937 0x106fb0154 
10 SfxDispatcher::ExecutePopup(vcl::Window *, Point const *) dispatch.cxx 1785 0x106faf7b4 
11 sw::sidebarwindows::SidebarTextControl::Command(CommandEvent const&) SidebarTxtControl.cxx 443 0x442bc7048 
12 weld::CustomWeld::DoCommand(CommandEvent const&) customweld.cxx 93 0x11284d438 
13 weld::CustomWeld::LinkStubDoCommand(void *, CommandEvent const&) customweld.cxx 91 0x11284cf84 
14 Link<CommandEvent const&, bool>::Call(CommandEvent const&) const link.hxx 105 0x112002f6c 
15 SalInstanceDrawingArea::CommandHdl(CommandEvent const&) salvtables.cxx 6559 0x112897380 
16 SalInstanceDrawingArea::LinkStubCommandHdl(void *, CommandEvent const&) salvtables.cxx 6557 0x112895000 
17 Link<CommandEvent const&, bool>::Call(CommandEvent const&) const link.hxx 105 0x112002f6c 
18 VclDrawingArea::Command(CommandEvent const&) layout.hxx 679 0x11206e704 
19 ImplCallCommand(VclPtr<vcl::Window> const&, CommandEventId, void const *, bool, Point const *) winproc.cxx 229 0x1121877a0 
20 ImplHandleMouseEvent(VclPtr<vcl::Window> const&, NotifyEventType, bool, long, long, unsigned long, unsigned short, MouseEventModifiers) winproc.cxx 798 0x112186ab0 
21 ImplHandleSalMouseButtonDown(vcl::Window *, SalMouseEvent const *) winproc.cxx 2338 0x11218aeb4 
22 ImplWindowFrameProc(vcl::Window *, SalEvent, void const *) winproc.cxx 2683 0x112189cb8 
23 SalFrame::CallCallback(SalEvent, void const *) const salframe.hxx 311 0x1118cccf8 
24 -[SalFrameView sendMouseEventToFrame:button:eventtype:] salframeview.mm 1093 0x111976474 
25 -[SalFrameView rightMouseDown:] salframeview.mm 1160 0x111976a98 
26 _routeRightMouseDownEvent (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19bb79308 
27 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b11bec4 
28 -[NSWindow(NSEventRouting) sendEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b11bb50 
29 -[NSApplication(NSEventRouting) sendEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b9580b8 
30 -[VCL_NSApplication sendEvent:] vclnsapp.mm 203 0x111982450 
31 AquaSalInstance::DoYield(bool, bool) salinst.cxx 609 0x1118e76d4 
32 ImplYield(bool, bool) svapp.cxx 385 0x112914a18 
33 Application::Yield() svapp.cxx 488 0x1129142d0 
34 Application::Execute() svapp.cxx 360 0x112913fac 
35 desktop::Desktop::Main() app.cxx 1679 0x100a6fe04 
36 ImplSVMain() svmain.cxx 230 0x112935fd8 
37 AquaSalInstance::handleAppDefinedEvent(NSEvent *) salinst.cxx 449 0x1118e68d8 
38 -[VCL_NSApplication sendEvent:] vclnsapp.mm 93 0x11198203c 
39 -[NSApplication _handleEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b55f4e8 
40 -[NSApplication run] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19afe8088 
41 NSApplicationMain (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19afbe854 
42 AquaSalInstance::SVMainHook(int *) salinst.cxx 1107 0x1118ebaec 
43 ImplSVMain() svmain.cxx 223 0x112935f8c 
44 SVMain() svmain.cxx 248 0x112937aac 
45 soffice_main sofficemain.cxx 122 0x100aef61c 
46 sal_main main.c 51 0x100003f70 
47 main main.c 49 0x100003f48 
48 start (arm64e) /usr/lib/dyld 0x197024274 

Frame 4 is making use of the parent window, which is already disposed at this stage without the fix from comment 39.

Therefore, I'm somewhat optimistic that the original issue that this ticket was about is fixed now, too. -> Closing this ticket as fixed.

@Reporter: A retest with a current daily build to see whether it's fine for you as well now would be welcome. Feel free to reopen if it still crashes for you.

Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 4906f11d8f0c85248464b10c0b6c9c02e1657bad
CPU threads: 10; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded
Comment 42 Heiko Tietze 2025-02-05 08:57:58 UTC
Verifying with 

Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 2cd3c9fdd05336b17bda301eb37c1ca86b062052
CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+xcb)
Locale: de-DE (en_US.UTF-8); UI: en-US
Calc: threaded

Thank you, Michael! Please cherry-pick to 25.2
Comment 43 Michael Weghorn 2025-02-05 11:02:29 UTC
(In reply to Heiko Tietze from comment #42)
> Please cherry-pick to 25.2

Already pending in Gerrit, waiting for reviewers:
https://gerrit.libreoffice.org/c/core/+/181134
Comment 44 Commit Notification 2025-02-05 22:25:13 UTC
Michael Weghorn committed a patch related to this issue.
It has been pushed to "libreoffice-25-2":

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

tdf#164072 sw annotation: Use menu parent that outlives menu

It will be available in 25.2.1.

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.