Created attachment 81477 [details]
The attached test file contains the same diagrams on the sheets. Inserting an empty row before the data rows results data integrity problem: the diagram on the second sheet will have bad data range (missing data range update). Undo doesn't help to restore the original data range of the charts. Checked with LO 4.0.4, too. The phenomenon depends from the size/empty charts of the second sheet, and other operations, but it is significant on the newly loaded test file.
There is a workaround for this bug: renaming the first sheet after opening the file will keep data integrity of the diagrams during row insertion/deletion.
(detected in LO 188.8.131.52, maybe wrong in older LO 4 versions, too.)
(In reply to comment #0)
> The attached test file contains the same diagrams on the sheets. Inserting
> an empty row before the data rows results data integrity problem: the
Is there any inteference with the setting in Calc that extends references when rows/columns are inserted at the edges of ranges?
( Tools > Options > Calc > General ..)
(In reply to comment #2)
There is no interference. This is a malfunction, because it occurs only in special circumstances, eg. on a sheet with many (~20) diagrams, also it is a regression, because LibreOffice 3 has no problem with it.
It is a problem of work sheets with multiple charts (not only multiple empty charts, the original document contains more data and non-empty charts).
Muthu - a chart regression :-) no idea if you have any insight off-hand into that ?
No idea...let me check...
I tried to find the issue for quite some time now.
I checked on different versions of LO and all looked alike :(
(And the language in the sheet is not helping as well :( )
Could you provide a detailed step wise info about how to reproduce the problem, please?
I also didn't understand what you mean by "Inserting an empty row before the data rows results data integrity problem"
It would help if you could attach screenshots as well, please?
Really sorry to be troubling you...
Created attachment 83429 [details]
Screenshots of sheet 2 after row insertion in sheet 1
Muthu : I have downloaded the test file, and inserted an empty row in the sheet 1 in the row 3 (before the data). In LibreOffice 3, all chars show the correct data range, in LibreOffice 4, the second chart on the sheet 2 will be bad (see the attached screenshots). Thanks for your checking!
Thank you, for the information. It took some more time to understand the problem :)
One more important point is:
The row needs to be inserted before opening Sheet2.
i.e. if we click on Sheet2 and back to Sheet1_2 and then insert the row - the chart data ranges are updated properly.
(This is an automated message.)
Setting priority to highest as this is a 4.0 MAB. This is part of an effort to make the importance of MAB reflected in priority too.
Could someone please test this to see if it is still an issue in 4.1 and/or 4.2? We are trying to close mab4.0 as it reached its end of life (EOL). Cheers.
(In reply to comment #12)
> Could someone please test this to see if it is still an issue in 4.1 and/or
> 4.2? We are trying to close mab4.0 as it reached its end of life (EOL).
It is still an issue in 4.2, I have tested it.
Thanks for testing! Moving this to mab4.1 as 4.0 reached end of life a while ago.
(In reply to comment #13)
> It is still an issue in 4.2, I have tested it.
your message was from february 2014, would you please give us an update with current 184.108.40.206?
if issue persists I'll move it to mab4.2 list
Works for me with:
Version: 220.127.116.11 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24)
Version: 18.104.22.168 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
Version: 22.214.171.124 Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Version: 126.96.36.199 Build ID: d7dbbd7842e6a58b0f521599204e827654e1fb8b
Version: 188.8.131.52 Build ID: 3be8cda0bddd8e430d8cda1ebfd581265cca5a0f
Version: 184.108.40.206 Build ID: 882f8a0a489bc99a9e60c7905a60226254cb6ff0
Version: 220.127.116.11 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Version: 18.104.22.168.0+ Build ID: da62ab5783e548c5785b3950c03d078b1f3e849d
TinderBox: Win-x86@42, Branch:libreoffice-4-2, Time: 2014-05-16_08:13:28
Version: 22.214.171.124.alpha1+ Build ID: 48eccfb812284f43ba24c3be3903537ce954944d
TinderBox: Win-x86@39, Branch:master, Time: 2014-05-16_00:35:19
Inserting a couple of rows in Sheet1_2.A2 or A10 updates properly the chart in Sheet2.C4, as first action without go to Sheet2, following what Muthu explains in comment#10, and no matter if the option about expand references explained by Cor in comment#2 is activated or not.
Perhaps an issue in relation with the user profile.
LibreOffice 126.96.36.199 release
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ f91a107c097e5932ba1ed1d88e574e900ebfda00 is the first bad commit
Author: Bjoern Michaelsen <email@example.com>
Date: Tue Dec 11 10:20:39 2012 +0000
Author: Takeshi Abe <firstname.lastname@example.org>
AuthorDate: Wed Dec 5 08:33:07 2012 +0900
Commit: Takeshi Abe <email@example.com>
CommitDate: Wed Dec 5 10:42:17 2012 +0900
sal_Bool to bool
:100644 100644 42f18f15fb3370ca3f85d6a637b17ae05b10996f 4e4564a1257d79f9fd86b264270d348bf06d23e3 M autogen.log
:100644 100644 b4973c1d86cfd5c0d550e84e7e483802d979829e 1224d320eac5e10b39e8481456547368fe09c748 M ccache.log
:100644 100644 a0e5b02e554537a0bed70a3203ca3995bb6972bd ab62cc407b67c0ca8a1a96f877dc86a92f01e1ef M commitmsg
:100644 100644 6ba1538977f3fb5b8f0ee54bbd04be28afdd85e3 575f5b911fb36490ff12ae85452ce424b34a3382 M dev-install.log
:100644 100644 dc4842a6e74513bbe562bb0d78a1ed545ead53e7 3f76084c0057251a1332a9be8b51e31a06e5590e M make.log
:040000 040000 e70233c1668fc1da017a420ac2ed5ee366e253ad 9457873d1fe1b1108dc20777c8f0180cefe48cdd M opt
# bad: [793dbf6f80f497dfe587d560d6257f42a24273f6] source-hash-1581b1fc3ac82a7bd62df968226e98604a4ca52d
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# bad: [8092559c5013969ebda017d79200463b9b975038] source-hash-fd84daf696a368c2c7561b5253b32a63ecdeca4a
git bisect bad 8092559c5013969ebda017d79200463b9b975038
# good: [2bdbcaf93e4616633a733de7eb88ba19571929ac] source-hash-cf04745f7a027594fd64a493c276a8280dbccfe1
git bisect good 2bdbcaf93e4616633a733de7eb88ba19571929ac
# good: [f823dd19086ed09fb8e2072050e963cf1bfcd5fe] source-hash-b679a2a02180c017bd8b596fb2e4f283bad93b75
git bisect good f823dd19086ed09fb8e2072050e963cf1bfcd5fe
# good: [8cf46b05e525ac3602433613f227f0dcacc44035] source-hash-1692cf6854ff7adbb2bd47f2f7ec2b3de51864f3
git bisect good 8cf46b05e525ac3602433613f227f0dcacc44035
# good: [3cb56a12a43a7c2a43954dc7694a6f6bde544f98] source-hash-41c2b0375773b2d2945d75e255ea6bb6c7fd378d
git bisect good 3cb56a12a43a7c2a43954dc7694a6f6bde544f98
# bad: [f91a107c097e5932ba1ed1d88e574e900ebfda00] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
git bisect bad f91a107c097e5932ba1ed1d88e574e900ebfda00
# good: [6590d64c096bc4ea15e3ae66f07a21392e8ba11c] source-hash-b67a51b40a4876f4bd97a2917103112006710b0c
git bisect good 6590d64c096bc4ea15e3ae66f07a21392e8ba11c
# good: [1bac3450cfb9ea0163e761f3c3751ed0b1340af3] source-hash-4026e1824de8ff9b5d006ae6eba491f91bc4e599
git bisect good 1bac3450cfb9ea0163e761f3c3751ed0b1340af3
# good: [a2876016251884845497fc1905d94e469a999204] source-hash-ce90f99a2d66c2b998ad3f9f028e2ea623a757f5
git bisect good a2876016251884845497fc1905d94e469a999204
# first bad commit: [f91a107c097e5932ba1ed1d88e574e900ebfda00] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
Go to Tools - Options - LibreOffice - Memory, and check your setting for "Number of objects". The default is 20. Increase that to something like 100. Restart LibreOffice and give this document another try. Will that improve that situation a bit?
See if this commit
helps the situation. That change makes chart objects exempt from automatic unloading per this configuration setting.
(In reply to comment #18)
> Go to Tools - Options - LibreOffice - Memory, and check your setting for
> "Number of objects". The default is 20. Increase that to something like
> 100. Restart LibreOffice and give this document another try. Will that
> improve that situation a bit?
Yes, it solves the problem in this case. Thanks for this great workaround! But the result depends from the sum of the objects of all opened documents, and it needs to restart LibreOffice after the modified memory settings.
So - if changing that limit improves things, then Kohei's commit(s) on master should fix this. Can you re-try with a recent master build to verify ?
(In reply to comment #21)
> So - if changing that limit improves things, then Kohei's commit(s) on
> master should fix this. Can you re-try with a recent master build to verify ?
I tried with a recent master yesterday, so the commits have not solved this regression yet (but I haven't checked it without the second commit).
Changing the memory settings works with older versions, too.
I will check it without the second commit.
Only with the first commit [From the log: Revert "bnc#883684: Better fix for this." This reverts commit a0bd5587a5ac62974bdb10731d3fd21584521a72.], it works well. It seems, the second commit doesn't fix this issue, but I will check it again.
I have checked it again, first commit solves this issue, the second one doesn't!
We need a new solution for this. The first commit is a brute-force, non-elegant way of making the problem go away. Not the right fix.
We need a way to either reload objects to memory from persistent representation in case it gets notified of data updates, or a way to make such chart objects with active listening exempt from unloading. The first commit blatantly make all chart objects unloadable, which is not elegant.
BTW, it may not just be chart objects that have listener capability, so we need to fix it correctly so that it would apply to other types of OLE objects with listener capability.
REOPENED is wrong status for this bug as it's not assigned to a developer. That being said, it looks like it's been confirmed so marking as NEW.
please give an update of the bug status with current LibO 188.8.131.52 or 184.108.40.206 beta.
we are in the process of migrating all 4.2.x MABs which are still reproducible to the MAB 4.3 list
(In reply to László Németh from comment #0)
Open 'test data' ODS
Click on "Sheet2" to view diagram (and (optionally) compare to screenshot attached to this bug). See that bars are increasing.
> Inserting an empty row before the data rows
Click on the "4" of row 4 and Insert -> Rows
> diagram on the second sheet
Click on "Sheet2" to view diagram again (bars should remain the same, but if the bug is present, will be decreasing)
> diagram on the second sheet will have bad data range (missing data range
CONFIRMED on Ubuntu 14.04
Testing with LO 220.127.116.11 and 18.104.22.168.beta2
> Undo doesn't help to restore the original data range of the charts.
CONFIRMED as well.
Moving mab4.2 -> mab4.3
still reproducible with LibO 22.214.171.124 under Win7x64
Migrating Whiteboard tags to Keywords: (bibisected)
Created attachment 128654 [details]
Simple test case with just one chart on each sheet
Still a problem with LibO v. 126.96.36.199 on both Win10 and WinVista.
The headline and some of the comments relate the problem to having a high number of objects. However, this simple test example with just two charts (on Sheet1 and copy on Sheet2) gives similar problems.
1) Open the Calc file.
2) Check that the charts on Sheet1 and Sheet2 are identical. They both show the data from Sheet1.
3) Close Calc.
4) Re-open the file.
5) Insert a new row in Sheet1 as the first row (i.e. "above" the data). The chart on Sheet1 is (correctly) not changed.
6) Check the chart of Sheet2. This is now (incorrectly) changed. More precisely, the chart on Sheet2 refers to the original row numbers, not the original data.
In line with comment #10, the chart on Sheet2 _is_ updated if the chart has been viewed (or perhaps only if it has been viewed/updated recently?). This is the reason for step 3-4 above.
It seems from the comments that people agree that this is a serious bug. Yet, it is unsolved after 3 years and development from LibO 4.0 to present 5.2. Is it a very difficult problem? (I know that bugs do not disappear by themselves, and I have a high regard for everybody working on eliminating bugs and developing LibO.)
Regression introduced in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=ce90f99a2d66c2b998ad3f9f028e2ea623a757f5..2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
Problem still present in the upcoming version 6.0.0 (from test of 188.8.131.52). As mentioned in comment #1, a workaround is to rename the charts before making the change. (This is not very logical, but seems to work.)
Dear DHARA BHAVSAR,
This bug has been in ASSIGNED status for more than 3 months without any
activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Changed the headline - as demonstrated by comment 32, the problem is not the number of objects. The word "non-active" in the new headline is a qualified guess - again, see comment 32.
And yes, the bug is stil present - I just tested with the current fresh version 6.2.3
Version: 184.108.40.206 (x64)
Build ID: aecc05fe267cc68dde00352a451aa867b3b546ac
CPU tråde: 4; Styresystem: Windows 10.0; Gengiver af brugergrænseflade: GL; VCL: win;
Lokalisering: da-DK (da_DK); Sprog for brugergrænseflade: da-DK
Tested in LO 220.127.116.11 according to recipe in comment 32. Bug is still present.
Version: 18.104.22.168 (x64)
Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win
Locale: da-DK (da_DK); UI: en-GB
Dear László Németh,
To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.
There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.
If you have time, please do the following:
Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/
If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.
Please DO NOT
Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not
appropriate in this case)
If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/
2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword
Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
Some version of this bug is still present in LO 22.214.171.124.
Using the original test data from comment 1, I fail to reproduce the bug. However, using my own test sample from comment 32, I can still reproduce the bug as described in that comment.
(Admission: I have realized that the diagram on Sheet1 is faulty - it has an internal data table rather than referring to the data in the sheet. However, the bug represents itself in the diagram in Sheet2, which DOES refer to the data in Sheet1. I.e., the test case is still relevant as described in comment 32.)
Thus, it is still the case that a diagram that has not been viewed, may fail to update its data references when these data moves, e.g. because of insertion of a row. And it is still the case that viewing the diagram before the insertion somehow "activates" that diagram, causing correct update of the data references in the "activated" diagram.
Version: 126.96.36.199 (x64) / LibreOffice Community
Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: da-DK (da_DK); UI: da-DK