Description: when inserting rows in a long file with 'stacked columns' (long columns summed up bottom-to-top with cells from two other columns) and filling the inserted rows with copies from 'working' rows above or below the gap i get error 522 sometimes somewhere - see attached screenshot in next comment. ctrl-shift-F9 or inserting other copies corrected the fault up to now, but i think that shouldn't be neccessary, the sheet should be able to insert and calculate the formula in the same way as it does for the other lines. Steps to Reproduce: not so easy, i took one row from my 'big sheet', copied it in rows 1 to 100 on another, inserted lines 6 to 10, copied line 15 to 4 - 12, got the error in lines 1 and two, cutted all stuff around, can provide screenshot, see attached. on save-load the error disappears as well as on strg-shift-F9, thus i cannot provide the file with error. Actual Results: a cell with a clear simple formula without any circular references or similar is calculated to Err:522, Expected Results: the cell should be calculated to a proper value instead, strg-shift-F9 or other actions shouldn't be neccessary while autocalculate is on Reproducible: Sometimes User Profile Reset: No Additional Info: Version: 6.3.0.0.alpha0+ (x64) Build ID: 5a907fe76bc628629fddb5501727642468d38dae CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-03-22_00:18:04 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded hardware / os: not tested with 'all', only win7(x64) on lenovo notebook, it looks like that the error likes to come up when you copy the formula in the gap with some overlap, e.g. insert 5 rows and copy the source row to nine rows two above and two below the gap, thus replacing rows with an identical copy
Created attachment 150180 [details] calc_6.3.0.0.alpha0_error_522_2 screenshot for filed bug ...
forgot: the formula in B3 is a relative copy of B4, '=round(B4+sum(C3;D3);2)', i found one similar - old - report: https://listarchives.libreoffice.org/global/users/msg29316.html
But without a sample file for test to reproduce the issue, how to find out what it's happening? Please attach a sample file as simple as possible.
Created attachment 150223 [details] file where err:522 on insert is reproducible, 6_3_522_on_insert ok, got it reproducible (hope so, sometimes errors change on save-load :-( in this file i had errors after fresh loaded) srry for the big file, a try with a shortened version (deleted all below row 20) fails (to fail). maybe simpler samples fail too steps to reproduce: 1. in attached file, 2. with lo-calc 6.3.0.0.alpha0+ from 2019-03-22_00:18:04, 3. mark rows 6 to 10, 4. insert empty rows with 'alt-s-r-a', 5. mark row 13, 6. copy it with 'ctrl-c', 7. mark rows 4 to 12, 8. paste with 'ctrl-v', 9. if active confirm pasting in filled cells, observe results in rows inserted and / or rows above, i got different occurrences of err:522, mostly in row 1 and 2 - which are not even touched by the insert ... the fail in col. C is initial, col. E and G are dependent, - imho not only 'repaint' problem, it persists on scrolling, and calculations referencing the shown '522' fail, - forced recalc - 'strg-shift-F9' - corrects the problem, showing (imho): a.) the calculations are 'possible' and calc is able to do them, b.) something is broken in the area / procedure / chaining when and what shall be (re)calculated pls. check reproducibility on other systems and with simplified files ... reg. b.
two other procedures to show a bug in above version / file: A: mousedrag: 1. with file and prog ver. from comment 4, 2. delete - the content!, not the rows - everything below row 1, 3. mark / select range A1:G1, 4. 'expand' it with the mouse for some rows below, 5. observe getting correct results for 1 to 50 rows (most times), 6. observe getting err:522 when pulling 100 rows or more (almost ever), 7. think that there's something wrong, - assumption: 'recursion' of autocalculate for 'shared formula groups' with dependent / referenced cells (ranges) is still broken or 'limited', 8. observe that forced recalc (strg-shift-F9) corrects the problem, 9. fault seems dependent on some complexity of the formulas and dependencies, boiling down to simpler constructions gave correct calculations - as far as i tested - B: copy-paste 1. with file and prog ver. from comment 4, 2. delete - the content!, not the rows - everything below row 1, 3. mark / select range A1:G1, 4. copy withe ctrl-c, 5. mark range A2:A100, 6. paste there with 'ctrl-v', 7. observe correct results, 8. mark cell C2 and cut with 'ctrl-x', 9. observe err:522 in cells C3 to C99, while formula in C99 references only correctly calculated and shown cells, 10. think that there's something wrong, - assumption: 'shared formula groups' are in the game as the error affects cells which are not! connected to the 'cut', besides they are copies into the same group ... 11. observe that forced recalc (strg-shift-F9) corrects the problem, 12. be aware that the need of forced recalc is almost ever a signal for something around autocalculate being broken, - assumption: the code area where the faults for bugs tdf#123714 and tdf#123736 had been, and the fixing done there, should be re-checked, reg. b.
reproducuble with: Version: 6.3.0.0.alpha0+ (x64) Build ID: f8251c40b4c512b6ea54ea2207a3816d8b925711 CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded steps to reproduce: - open attached spreadsheet - select A2:G1027 - delete content - select A1:G1 - drag down cell range for ~1000 rows -> Err:522 - hard recalc fixes Err:522 but *not* reproducible, if "Calc: threaded" is disabled: Menu Tools/Options.../LibreOffice Dev Calc/Calculate CPU threading settings [ ] Enable multithreaded calculation restart LO after change
Regression introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=906b505940f6330d2336164f341e338ff4b9b9ee author Luboš Luňák <l.lunak@collabora.com> 2019-01-25 15:08:16 +0100 committer Luboš Luňák <l.lunak@collabora.com> 2019-01-28 11:01:06 +0100 commit 906b505940f6330d2336164f341e338ff4b9b9ee (patch) tree 87de1e848215c0c0cfb22017fd859d807e87f482 parent 6f5991261a152812d5023fd146398c1528683676 (diff) avoid a calc threads assert because of an undetected cyclic dependency Bisected with: bibisect-linux64-6.3 Adding Cc: to Luboš Luňák
nobody worked on it? but no-repro in Version: 6.3.0.0.alpha1+ (x64) can somebody recheck? if no error 'wfm'. reg. b.
forget previous comment, it 'happened again', on copying! 21 lines in a large sheet with simple! calculations 'stacking up' from each previous line: 'error 522' two lines above! the area touched by insert in every column where the formula is referencing the cell underneath. ctrl-shift-F9 corrects the problem, thus a problem of autocalculate, (analysis), the problem affects areas with 'shared formulas', thus implementation of that still buggy, (assumption), the problem occurred with *threaded* enabled, thus a special case of distribution of shared formulae between threads, (assumption),
Created attachment 154135 [details] screenshot with faulty calculation hi there, sorry for insisting, the problem ist still apparent in: Version: 6.3.0.0.alpha1 (x64) Build ID: 547edd20e527fb02900f6174973770d26306e2e7 CPU threads: 8; OS: Windows 6.1; UI render: default; VCL: win; Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded cross checked: calc set to 'threaded', inserted about 12 empty lines, copied one working line with the formulas to the area 'one line above new space - free space - one line below thenew space' (to correct the 'expanded' formulas where the reference to the line below is held on insert and now points 13 lines below), two lines above the insertion area: error 522 in all columns with stacked formulas. calc reset to 'unthreaded', same procedure as above, no error. strg-shift-F9 'corrects' the error, thus still a problem of the combination of autocalculate and shared formulas, but occuring only in threaded mode. i'd be very happy if someone looks for it and brings calc 'threaded' back to a working state. reg. b.
*** Bug 127789 has been marked as a duplicate of this bug. ***
Can be easily reproduced by opening https://bugs.documentfoundation.org/attachment.cgi?id=154545 Increasing severity...
@Xisco as you and others can confirm the error, and as you know where it's evolving from, why not throw out that commit until a repaired version is available? - other modules may be affected by the buggy patch? that's an argument, but that all subsequent work implies the defect and may produce more erroneus dependencies is an argument not! to keep it. - this commit repairs something important? then it's urgent to work on it ... besides: ver 6.2.7.1 win(x64) looks quite healthy at first, it's the best version i've seen yet, but also in this version i had - very few but i had - appearences of wrong err:522's when working 'threaded'. the 'threading' module - 'i assume' - probably still contains some hard to find bugs. reg. b.
I cannot reproduce this using the steps in comment 6 on master branch with HEAD at 46d0afba738d8ee7c9b63384fef513f42ee587f3 Version: 6.4.0.0.alpha0+ Build ID: cf43869d9226444b1295055382e7ff5c2c698e31 CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Dennis Francis from comment #14) > I cannot reproduce this using the steps in comment 6 on master branch with > HEAD at 46d0afba738d8ee7c9b63384fef513f42ee587f3 > > Version: 6.4.0.0.alpha0+ > Build ID: cf43869d9226444b1295055382e7ff5c2c698e31 > CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; > Locale: en-US (en_US.UTF-8); UI-Language: en-US > Calc: threaded Hi Dennis, you can easily reproduce it with this file: https://bugs.documentfoundation.org/attachment.cgi?id=154545 from bug 127789. Check columns H,I,K
> > Hi Dennis, you can easily reproduce it with this file: > https://bugs.documentfoundation.org/attachment.cgi?id=154545 from bug > 127789. Check columns H,I,K Yes I checked that file, but seems it is a different problem (but could be related) because in that document, Err:522 does not go away with a hard-recalc, but the current bug's original reporter says the Err:522 go away with a hard-recalc.
Created attachment 154806 [details] Sample file showing the bug at opening. With 'thread' enable at opening attached file shows the errors, hard recalc works, but after that saving and reopening shows the errors again. Disabling thread seems to solve the issue.
(In reply to m.a.riosv from comment #17) > Created attachment 154806 [details] > Sample file showing the bug at opening. > > With 'thread' enable at opening attached file shows the errors, hard recalc > works, but after that saving and reopening shows the errors again. > Disabling thread seems to solve the issue. Hi there, As stated in my comment 5 here : https://bugs.documentfoundation.org/show_bug.cgi?id=127789#c5 Disabling thread only seemed to solve the problem. No "Err :522", but erratic result judging by the discontinuous red curve obtained on the graphs, on FiltrageVent sheet. I tried that on build 6.3.2.2 Best regards, Guillaume AMELINE
*** Bug 128517 has been marked as a duplicate of this bug. ***
Dennis Francis committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0f4ba703038fb8678d4b1e7e6e0fd5e2d3025908 tdf#124270 : improve formula-group cycle detection It will be available in 6.4.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.
Dennis Francis committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/989240664c33bc83800e27c1c0e718294321f46a tdf#124270 : unit-tests for spurious Err:522 fixes It will be available in 6.4.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.
This is fixed for 6.4, now I need to port my patch to 6.3.
(In reply to Dennis Francis from comment #22) > This is fixed for 6.4, now I need to port my patch to 6.3. Hi Dennis, thanks for fixing this issue. Your commits rely on https://cgit.freedesktop.org/libreoffice/core/commit/?id=845e1cdca3349c72e3083186502285d5b776abbe which makes it not straightforward for the backporting
(In reply to Xisco Faulí from comment #23) > Hi Dennis, thanks for fixing this issue. > Your commits rely on > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=845e1cdca3349c72e3083186502285d5b776abbe which makes it not > straightforward for the backporting Yes, I'm working on it.
Dennis Francis committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/c54c5d872ad464985ca974a7fcf28bef54530b43 tdf#124270 : improve formula-group cycle detection It will be available in 6.3.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.
Dennis Francis committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/94b2724268e8c394b90b8971171f4d038cd74088 tdf#124270 : unit-tests for spurious Err:522 fixes It will be available in 6.3.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.
Wow... Thank you very much for the fix! My project works perfectly on 6.3.4, Windows 8.1 and Windows 10. I will test it with Ubuntu 18.04 soon. I am just amazed at how complicated it must have been.