Bug 119954 - Using a second defined database range in formula expression switches to first range.
Summary: Using a second defined database range in formula expression switches to first...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: target:6.2.0 target:6.1.3 target:6.0....
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-18 10:24 UTC by Eike Rathke
Modified: 2019-12-07 15:24 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eike Rathke 2018-09-18 10:24:36 UTC
* new document
* in A1 enter 1
* in C3 enter 2
* on A1 define a database range 'aaa' with $Sheet1.$A$1
* on C3 define a database range 'bbb' with $Sheet2.$C$3
* in any cell enter formula =bbb
  => result is 1 instead of 2
* place cell cursor on that formula cell again
  => see that the formula is =aaa instead of =bbb

The problem does not occur with a third defined database range. The problem seems to be gone once the document is saved and reloaded, then =bbb is accepted as is.
Comment 1 Eike Rathke 2018-09-18 10:46:51 UTC
On Linux I can reproduce only in a master/6.2 debug build, not 5.4.7 nor 6.0.6 nor 6.1.0 (didn't try the final 6.1.1 yet).
Comment 2 Eike Rathke 2018-09-18 15:19:44 UTC
So this is some memory mismanagement accessing an ScDBCollection::maNamedDBs::mrParent where the mrParent ScDBCollection was already destroyed, which happens in ScDBDocFunc::ModifyAllDBData() where rNewColl.maNamedDBs.mrParent is a reference to the ScDocument's ScDBCollection which (the mrParent) gets copy-constructed to the new ScDBCollection but then the existing one gets destroyed when setting that new one with

  rDoc.SetDBCollection( std::unique_ptr<ScDBCollection>(new ScDBCollection( rNewColl )) );

This probably never worked correctly since the ScDBCollection::maNamedDBs::mrParent reference was introduced, but may have different effects on different platforms with different compilers and options, depending on memory initialization.

Using weak_ptr and shared_ptr instead of unique_ptr, or some other reference mechanism and life cycle management is necessary.
Comment 3 Oliver Brinzing 2018-09-18 16:56:06 UTC
i can not reproduce this bug with:

Version: 6.2.0.0.alpha0+ (x64)   (DEBUG Build)
Build ID: 7595fce391ba2aca49db87c93006302d0c2a64f2
CPU threads: 4; OS: Windows 10.0; UI render: default; 
Locale: de-DE (de_DE); Calc: threaded

Version: 6.1.1.2 (x64)
Build-ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc:
Comment 4 Jurijs 2018-09-19 05:05:03 UTC
I can reproduce this bug:

Version: 6.0.4.2 Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 2; OS: Windows 6.1; UI render: default; Locale: en-GB (lv_LV); Calc: group
Comment 5 Commit Notification 2018-09-20 20:01:47 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7ea5d339dc4d8412f436f3affa589bfbd0b1ef68

Resolves: tdf#119954 do not copy the old parent, init with new parent instead

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 6 Eike Rathke 2018-09-20 20:03:44 UTC
Pending review
https://gerrit.libreoffice.org/60841 for 6-1
https://gerrit.libreoffice.org/60842 for 6-0
Comment 7 Commit Notification 2018-09-26 10:47:14 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd81c31a6c5313c53269721749f7bcdc11a103ad&h=libreoffice-6-1

Resolves: tdf#119954 do not copy the old parent, init with new parent instead

It will be available in 6.1.3.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2018-10-03 13:50:56 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8755c98657b0ab5a08742f38d7856ca63de3ffeb&h=libreoffice-6-0

Resolves: tdf#119954 do not copy the old parent, init with new parent instead

It will be available in 6.0.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2018-12-16 13:04:03 UTC
Zdeněk Crhonek committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/7e7e203c26f0b22973aa65f163a8590d8313250d%5E%21

uitest for bug tdf#119954

It will be available in 6.3.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 raal 2019-12-07 15:24:12 UTC
The test exist, set status to Verified.