https://bugs.documentfoundation.org/show_bug.cgi?id=113647
Mike Kaganski <[email protected]> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from Mike Kaganski <[email protected]> ---
Reproducible with
Version: 6.0.0.0.alpha1+ (x64)
Build ID: b03fe77699b1ad30a9441bd9b283f25579ac261e
CPU threads: 4; OS: Windows 10.0; UI render: GL;
Locale: en-US (ru_RU); Calc: CL
and
Version: 5.4.2.2 (x64)
Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
CPU threads: 4; OS: Windows 6.19; UI render: GL;
Locale: ru-RU (ru_RU); Calc: CL
Code pointers for an interested developer:
The crash happens because Dialog::ImplStartExecuteModal() tries to access
previous active modal dialog's member, but the previous active dialog is
already disposed of at that time (and
ImplGetSVData()->maWinData.mpLastExecuteDlg still points to that already
disposed dialog).
This happens (in case of gallery crash) in
GalleryBrowser1::ImplGalleryThemeProperties, where mpThemePropertiesDialog
(referencing the previous gallery dialog) is reassigned to a newly created
dialog, thus disposing previous one.
The problems:
1. It shouldn't be possible to operate on detached tools, like with attached;
so the reassignment wouldn't happen;
2. In that case, if we first checked for existence of the dialog, and possibly
just returned the already existing instance, it would work. Or maybe add an
assert that would express the invariant (that the mpThemePropertiesDialog must
be empty before assignment).
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
