Created attachment 153299 [details] The announced attachment. Contains macro! (See also code below.) A variable got assigned a component, another one an object emerging from that component. The component then was closed (doc.Close(True)). Expectations: Closing a document component should remove any non-Null assignment from variables previously giving access to it or to an object having emerged from that component. The variables should best get assigned the 'Null' value. Actual behaviour: After closing the document component, the IDE still shows the mentioned variables as if they still give access to the dead document and to the other object. Special aggravation: An attempt to inspect one of the phantom objects results in a complete crash of LibreOffice. Experience and tests with LibO V 6.3.0.2RC under Win 10 newest version as of 2019-08-10. MS Windows(TM) Version 1903 (Build 18362.267) "1903" should probably read "2019-03", but wisely MS indicates the corporation won't live to see the next century. Code: Sub test Dim nullOb As Object REM Usage see below! Dim doc As Object, Sheet As Object doc = StarDesktop.loadComponentFromUrl("private:factory/scalc", "_blank", 0, Array()) sheet = doc.Sheets(0) doc.Close(True) h1 = doc REM Assignment as if doc still is accessible! h2 = sheet REM Assignment as if sheet still is accessible! REM The following would help to avoid the crash. doc = nullOb sheet = nullOb End Sub For more details see attachment.
(In reply to Wolfgang Jäger from comment #0) > An attempt to inspect one of the phantom objects results in a complete crash > of LibreOffice. confirming crash with: Version: 4.4.7.2 Build-ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Gebietsschema: de_DE but no crash with LO Version 3.6.7.2 (Build ID: e183d5b) / AOO 4.1.5 adding a crash reprot from LO 6.3.0.4
Also reproducible in Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Created attachment 159520 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
Caolán: I made different tests and I noticed that I got a crash even before calling calling close function in macro. Above all, I noticed it was gtk3 specific (I don't reproduce this with gen rendering). Indeed, sometimes in WatchWindow::UpdateWatches, inside m_xTreeListBox->all_foreach([this, pCurMethod, bBasicStopped](weld::TreeIter& rEntry), pItem could be null. To reproduce this, I put "doc" for watch variable, then debug until doc is initialized. - Expand doc - Expand Reference Device - Expand Info - Unexpand Info - Expand FontDescriptor => crash Another remark: with gtk3 rendering, when editing macro to use debug, the current window isn't macro one but stays the main Writer window. With gen rendering, the current window becomes macro one (far more practical). If you want me to create a new bugtracker, don't hesitate to tell. I thought it could be related to this one.
I think https://gerrit.libreoffice.org/c/core/+/92283 would at least avoid the first reported crash
https://gerrit.libreoffice.org/c/core/+/92306 for the second, more recent, crash
by "with gtk3 rendering, when editing macro to use debug, the current window isn't macro one but stays the main Writer window" I imagine you mean that tools->macros->organize_macros->basic->(select macro)->edit appears behind the current window, not in front. I note tools->macros->edit macros seems to always appear in front not behind which is mildly interesting
my guess is that its probably the presence of the dialog that gets gtk to push the new window behind when it appears
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/db677c854a37031235b0f42b4f4f48560149754f tdf#126828 don't crash fetching cmis properties from disposed SfxBaseModel It will be available in 7.0.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ff8288b98f6975c7fc9f36155d26a44e8c625f94 tdf#126828 skip "on-demand" entries It will be available in 7.0.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cac8694feab1ccb422294ed3e2f8b682e15835fb tdf#126828 hide macro organize dialog before launching macro editing It will be available in 7.0.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.
Caolán: great, you indeed fixed the 3 issues! - the original one reported by Wolfgang - the one I had reported in comment 4 - the focus problem Thank you as always! :-) I let you decide to put this one to FIXED unless you prefer backporting all this on 6.4 branch before.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/dafa1bbf09e1df38cc0758b9f4c8a0ca186b31d2 tdf#126828 don't crash fetching cmis properties from disposed SfxBaseModel It will be available in 6.4.4. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/c737572cedceeec80ec38db0ad18278bbfdbc64a tdf#126828 hide macro organize dialog before launching macro editing It will be available in 6.4.4. 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.