Bug 124577 - clear reproducible error with combination of shared formulas, parallelized computing, autocalc weakness, see comment c#10 | was: Copying by dragging calculates false values (different every time)
Summary: clear reproducible error with combination of shared formulas, parallelized co...
Status: RESOLVED DUPLICATE of bug 132451
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
Depends on:
Blocks: OpenCL Calculate Calc-Threaded
  Show dependency treegraph
Reported: 2019-04-06 11:11 UTC by zbrojny120
Modified: 2020-06-26 14:07 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Affected file (48.55 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-04-06 11:12 UTC, zbrojny120
shrinked sheet with the error still occuring (25.67 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-12-28 15:08 UTC, b.
124577_piraci_test8_ori, calculation error with threaded or openCL (22.75 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-01-28 12:24 UTC, b.
another file pinpointing the bug (34.87 KB, application/vnd.oasis.opendocument.spreadsheet)
2020-02-17 18:06 UTC, b.

Note You need to log in before you can comment on or make changes to this bug.
Description zbrojny120 2019-04-06 11:11:53 UTC
While doing some spreadsheet exercises I stumbled upon a strange problem. Every time I try to copy formula containing cells (selecting and dragging) the calculated values are different. I am attaching the file affected by this problem.

Steps to Reproduce:
1. Select cells A4:Q4
2. Drag them all the way down to row 152
3. Repeat 1. and 2. a few times to see how cell values change
4. Reopen the file, should be correct now

Actual Results:
Calculated values are wrong and different every time

Expected Results:
Calculated should be correct and identical every time. 

Reproducible: Always

User Profile Reset: Yes

Additional Info:
Closing and opening the file calculates correct values.
Comment 1 zbrojny120 2019-04-06 11:12:51 UTC
Created attachment 150564 [details]
Affected file
Comment 2 Oliver Brinzing 2019-04-06 12:06:08 UTC
Thank you for reporting the bug. 

To be certain the reported issue is not
related to corruption in the user profile, could you please reset your
Libreoffice profile ( https://wiki.documentfoundation.org/UserProfile ) and

And please copy information from Menu "Help/About LibreOffice"
so we can see the exact LibreOffice version you use.

> Actual Results:
> Calculated values are wrong and different every time

Does it work, if you do a hard recalc after dragging?
-> Menu "Data/Calculate/Recalculate Hard (Ctrl+Shift+F9)"

Have you tried with disabled:
Menu "Tools/Options/LibreOffice Calc/Calculate"
CPU Threading settings
[ ] Enable multi-threaded calculation 

I have set the bug's status to 'NEEDINFO'. 
Please change it back to 'UNCONFIRMED' once the requested info is provided.
Comment 3 zbrojny120 2019-04-06 13:32:28 UTC
I tried reproducing this bug in safe mode and the same thing happens. Libreoffice version I am using is the following:, Build ID: 20 (Build:2) (installed from Solus repositories). Pressing Ctrl+Shift+F9 after dragging corrects all the values. Disabling multi-threaded calculation seems to fix this problem.
Comment 4 Oliver Brinzing 2019-04-06 14:48:45 UTC
setting to "NEW" even if i can not reproduce at the moment, but it sounds understandable and seems to be related to/a duplicate of:

Editing: Err:522 on copying of rows with "Calc: threaded" enabled
Comment 5 b. 2019-04-11 17:59:56 UTC
instant repro with 

Version: (x64)
Build ID: 35d9a2618dc0116378ab795a7b9277d248c5afd4
CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-05_04:55:04
Locale: de-DE (de_DE); UI-Language: en-US
Calc: *threaded*

Err:522 in K153:N153

but not! repro with *not threaded*, three attempts, all identical, no err:

win 7 pro x64

os: not 'all', but linux and win
Comment 6 b. 2019-12-28 15:08:54 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2020-01-21 12:16:03 UTC
*** Bug 129753 has been marked as a duplicate of this bug. ***
Comment 8 b. 2020-01-22 09:16:33 UTC Comment hidden (obsolete)
Comment 9 b. 2020-01-28 12:24:17 UTC
Created attachment 157481 [details]
124577_piraci_test8_ori, calculation error with threaded or openCL

ok, as @xisco closed the simplified bug #129753 and thus it won't get much attention: 

the sheet presented by the OP for this bug is quite complex, too complex to get the error spotted and solved yet, it's hard to dig through it, 

i put in a simplified sheet here, it has two samples reduced to the minimum conditions where the error is appearing, and pinpointing the spot where the error starts, 

detailed info see into the sheet, 

condensed description: 'reproducible miscalculations with either threaded or openCL activated',

imho the bug is important as it will - often unnoticed - affect plenty results for users working with either openCL or 'threaded' calculation, wich is activated by default,  

it would be very helpful if a developer can have a short look at the attachement and decide if a reliable spreadsheet could possibly perform better than that, 

thanks, reg.  

Comment 10 b. 2020-02-17 18:06:18 UTC Comment hidden (obsolete)
Comment 11 Telesto 2020-04-26 21:28:31 UTC Comment hidden (obsolete)
Comment 12 b. 2020-04-27 07:37:46 UTC
hi :-) @Telesto, 

> new bug? 

i did, see c#8, xisco will 'ex-it-duplicate', 

> Version:

pls. recheck, i had completely crippled results already with ver, may be  your settings for dev/alpha ver. are different from those for standard ver.? openCL or threading or both are required and must be active - restart - for the bug to strike, 

in general: we have different views on the problems, 

i try to see the big picture, most testers and developers are oriented towards local phenomena? 

if you patch single aspects of a big bug locally you get ... a patchwork carpet which makes the big picture pixelated, and it's harder and harder to spot the basic problem. 

and if you do find it, it's very difficult to fix because changes will likely collide with the patches ... 

in this respect, excuse my approach and 'style' which is unusual for this forum, it's based on the best intention, 

and combining different approaches is one of the strengths of open software?

be sure i'll only complain in this style for problems which - i assume to be - based on fundamental problems not yet solved.
Comment 13 b. 2020-05-11 17:16:30 UTC
for the Bug Hunting Session 

still a bug with that ver., 

'second from top' of a 99+ column of identical (shared) formulas is sensitive against overpasting with copies from elsewhere in that column once three 'calculation-connected' cells per row, at least one calc-connection to prev. and subseq. row, and threaded or openCL active, 

imho critical as the error can lead to well hidden miscalculations ... as it did for th OP,
Comment 14 b. 2020-06-05 14:46:34 UTC
still odd with below ver., 

@Eike: think you solved some similar issues in the past, at least regarding autocalculate and shared formulas ... additional difficulty 'parallel computing' here ... minimum reproducer and sample in c#9 what someone liked to flag obsolete ... ???

@Telesto: imho those comments are valid and neccessary, and helpful as they ease the work of the devs by some steps in boiling down which can be done by 'nopros' like me, 

Version: (x64)
Build ID: 75e1cf6c6ea83e65da248dab917b06feea6c18e4
CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: CL
Comment 15 Telesto 2020-06-05 15:25:46 UTC
Bisected to
author	Dennis Francis <dennis.francis@collabora.co.uk>	2018-06-12 15:04:04 +0530
committer	Dennis Francis <dennis.francis@collabora.co.uk>	2018-06-21 15:04:11 +0200
commit 12782fc917bcdc1c119bda675fc27f77887498e0 (patch)
tree d0d990355644b71d4d8333fc7ffe5adbf3f1ab2e
parent 6b496d6a0f8b9de38fbf6721796104496d927db3 (diff)
Do dependency computation checks for OpenCL and...
software interpreter like in CPU threading.
This patch also reworks the cycle detection
to make it more robust.

Since the dependency computation also does
cycle detection, there is no need to disable
group-calc(threaded/OpenCL/SW Interpreter)
for non-leaf nodes in recursive interpret.

The rework of cycle detection ensures that
it fixes tdf#95748 correctly.

So same cause as bug 132451
Comment 16 Telesto 2020-06-05 15:35:17 UTC
(In reply to b. from comment #14)
> still odd with below ver., 
> @Telesto: imho those comments are valid and neccessary, and helpful as they
> ease the work of the devs by some steps in boiling down which can be done by
> 'nopros' like me, 

Checking if it's a regression and bibisecting a bug is more effective strategy compared to adding a random developer. You will will know if:
* it's a regression or not
* which code change caused the problem
* which developer you have to contact

It's a commit from Dennis Francis. He is already aware.. and assigned himself (bug 132451). Bibisecting is rather easy thing to do, and helpful: https://wiki.documentfoundation.org/QA/Bibisect
Comment 17 b. 2020-06-06 08:49:37 UTC
@Telesto: thanks for taking care of it, i had seen the other bug before but didn't remember ... i got out of step because - unusually - you continued the case under another bug, 

i think that's right because it frees the developers from the burden of 'finding comments' here, but usually @xisco almost immediately stops such things as duplicates (see fate of tdf#129753), 

thus i'll set this bug here to duplicate, and refer to the new ... 

--- set to duplicate of refined bug --- 
--- fixing and commenting should continue there ---

*** This bug has been marked as a duplicate of bug 132451 ***