Description: for the 'bug hunting session', the test from https://bugs.documentfoundation.org/show_bug.cgi?id=124577#c6 'minimum reproducer' still fails in ver: Version: 6.4.0.1 (x64) Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: en-US (de_DE); UI-Language: en-US Calc: threaded or CL it works well if set to 'unthreaded' and! 'un-CL', if either of them is activated it fails, strg-shift-F9 helps out, thus: - the sheet is computeable, - it's only autocalculate with a (new?) fail, i don't think 'use hard recalc' is an acceptable solution for users, the error is presenting wrong results, thus imho it's severe ... urgent suggestion: mark openCL and threaded as experimental while they are buggy, reg. b. Steps to Reproduce: 1. check which options you have enabled, either -tools-options-libreoffice-opencl-allowuseofopencl-, or -tools-options-libreoffice calc-calculate-enable multi-threaded calculation- will fail, both off will hold, 2. open file https://bugs.documentfoundation.org/attachment.cgi?id=156818 3. select and copy B4:H4 4. paste in B5:H5 5. check result in H5: 21 is wrong, 30 is correct, 6. trigger hard recalc, strg-shift-F9, see H5 changing, 7. conclude 'auto calculated result was wrong' 8. believe me or not, there is a fundamental error in how calc handles autocalc, shared formulas, dependencies and threading ... Actual Results: H5 calculated to / or presented as 21, Expected Results: H5: 30 as unthreaded or after hard recalc, Reproducible: Always User Profile Reset: No Additional Info: Version: 6.4.0.1 (x64) Build ID: 1b6477b31f0334bd8620a96f0aeeb449b587be9f CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: en-US (de_DE); UI-Language: en-US Calc: threaded as ver. 5.0.0.1 fails too - plenty wrong results on load of this file with openCL enabled, correctable with hard recalc, clean without openCL, i set first affected to this ver. i'd bet all prior versions with openCL are affected too,
for fast access for developers and an additional comment: open http://bugs.documentfoundation.org/attachment.cgi?id=156818 enable openCL or threaded calculation, copy B4:H4 to B5:H5, observe wrong result in H5 (21 instead of 30), correct result shows up with hard recalc, it works better if you delete row 103 ... funny ... all dependencies are simply within each row and with three simple references to the row above still wrong in ver: Version: 6.4.0.2 (x64) Build ID: 08d19fecdc7a2298d051e19cfdb7c35544855fc3 CPU threads: 8; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: CL could someone pls. recheck, thanks
the 'pain-point' is B5, (sorry, A5 is wrong, should be 1902-10-03, but doesn't affect this problem), if you copy any other cell from B4:B103 into B5 it pulls something of it's former value / references / dependencies into B5, the formula and result shown in B5 are correct, but dependent cells produce wrong results, e.g. col. H and col. D. i couldn't find anything 'unnormal' in the content.xml file, that as well as working corrct without threaded and CL show that it's a problem how parallelizing is handeled by calc.
Hi b, you don't need to create another issue for bug already reported. Instead, what you can do is: 1. Write a new comment saying: Still reproducible in <version> and the steps you used to reproduce it ( keeping them as simple as possible ) Long comments scare QA/Dev people Closing as a duplicate of 124577 *** This bug has been marked as a duplicate of bug 124577 ***
hello @Xisco: it is always a risky decision between a new bug, or digging around in old reports, in this case i made a new report regarding the bug hunting session, and because it's 'pinpointed', boiled down to the source of evil. and #124577 doesn't have 'threaded / CL' in the title, but it looks important for this bug. in #124577 the source is buried under so much other stuff that i could understand developers saying: 'to complicated, i look for easier work'. thus i'd suggest to keep this one active, and make 124577 the dup. reg. b.
a hint?, a question ... it looked interesting for me that this error is dependent of the sheet having rows down to 103, the error is off once you delete row 103. by chance i stepped onto 'something' into an old version of calc with experimental use of openCL (5.0.0.1): it has special settings when to use openCL, 'tools-options-LibreOffice Calc-Formula-Detailed Calculation Setting-Minimum data size for OpenCL use' ... that setting defaults to 100 ... it's only an idea, but i'd bet 100 EUR 1:1 that this bugs (129753/124577) behaviour needing a distinct number of rows to show up is a 'leftover' from this setting still being somewhere in the code, as the range B4 to B103 has exactly 100 cells, and thus anything triggered by testing if 100 formulas are available for openCL use would step in. (the error doesn't show up if parallelized calculation is switched off, it's supressed when less than 100 items are involved.) symptom pointing in that direction: if you insert a row between 102 and 103 the error is gone even with active openCL, if you create a second block of rows with identical content below row 104 (former 103) it will work error free until it's 101 rows long, after that dragging down row 105 to 204 gives wrong results again. why 101 rows and copying the second? the top one has different formulas referencing to row 102. this would / could mean that openCL (and threading?) are still buggy in principle (in conjunction with 'shared formulas'?), but often - wrongly - are considered 'fixed' because the tests are made with shorter blocks... ??? sorry @Eike, just 'assumptions' anyone to go for it?
Created attachment 157416 [details] testsheet_minimum_reproducer_with_instructions_124577_piraci_test5_ori reduced testsheet for bug 124577 / 129753, retype formula in A5 and observe wrong result in C5, error needs 'threaded calculation' or 'openCL' being activated, error seems activated by parallelized computing stepping in up from 100 identical formulas, error 'only' blocks autocalculate, but is not 'nice' as it produces wrong results, often far out from sight of user, i did what i can to pinpoint, @Eike: wouldn't the rest be a nice little job for you? reg. b.
*** This bug has been marked as a duplicate of bug 132451 ***