Bug 126828 - Variables having assigned objects from closed components pretend to still be valid. Attempts to inspect them in the IDE cause crashes.
Summary: Variables having assigned objects from closed components pretend to still be ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: BASIC (show other bugs)
Version:
(earliest affected)
4.1 all versions
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.0 target:6.4.4
Keywords: haveBacktrace
Depends on:
Blocks: BASIC-IDE
  Show dependency treegraph
 
Reported: 2019-08-11 16:33 UTC by Wolfgang Jäger
Modified: 2020-04-16 09:14 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["SfxBaseModel::getCmisProperties()"]


Attachments
The announced attachment. Contains macro! (65.85 KB, application/vnd.oasis.opendocument.text)
2019-08-11 16:33 UTC, Wolfgang Jäger
Details
bt with debug symbols (15.24 KB, text/plain)
2020-04-12 16:32 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Wolfgang Jäger 2019-08-11 16:33:18 UTC
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.
Comment 1 Oliver Brinzing 2019-08-11 17:06:15 UTC
(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
Comment 2 Xisco Faulí 2019-08-12 11:25:06 UTC
Also reproducible in

Version 4.1.0.0.alpha0+ (Build ID: efca6f15609322f62a35619619a6d5fe5c9bd5a)
Comment 3 Julien Nabet 2020-04-12 16:32:18 UTC
Created attachment 159520 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.
Comment 4 Julien Nabet 2020-04-13 13:03:49 UTC
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.
Comment 5 Caolán McNamara 2020-04-15 15:15:15 UTC
I think https://gerrit.libreoffice.org/c/core/+/92283 would at least avoid the first reported crash
Comment 6 Caolán McNamara 2020-04-15 15:33:52 UTC
https://gerrit.libreoffice.org/c/core/+/92306 for the second, more recent, crash
Comment 7 Caolán McNamara 2020-04-15 15:42:18 UTC
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
Comment 8 Caolán McNamara 2020-04-15 15:45:42 UTC
my guess is that its probably the presence of the dialog that gets gtk to push the new window behind when it appears
Comment 9 Commit Notification 2020-04-15 16:08:17 UTC
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.
Comment 10 Commit Notification 2020-04-15 18:14:12 UTC
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.
Comment 11 Commit Notification 2020-04-15 18:15:38 UTC
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.
Comment 12 Julien Nabet 2020-04-15 20:11:53 UTC
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.
Comment 13 Commit Notification 2020-04-16 05:20:46 UTC
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.
Comment 14 Commit Notification 2020-04-16 09:14:14 UTC
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.