Bug in LibreOffice 4.2.5.2, Windows 7 x64 Reproduce: 1. Create new Calc document 2. click on cell B2, enter "1" 3. click on cell C2, add reference to B2 by entering "=B2" 4. click on cell B2, press delete 5. note that cell C2 is showing "0" => as expected 6. click the undo button 7. Observe bug: Cell C2 is still showing "0", but should show "1" again! 8. Curiosity: If you reproduce steps above starting at cell "A1" the bug does not occur.
Reproduced with LO 4.3.0.2, 4.2.5.2, 4.2.0.0.beta1 - Ubuntu 12.04 x86 Hard recalc (ctrl-shift-f9) solves the problem Not reproduced with LO 4.1.6.2 Another variation of Bug 77944
I think it's not critical since we have a workaround: hard recalc. Set to high major
> I think it's not critical since we have a workaround: hard recalc. You're only speaking as a dev here... As an ordinary user I have never heard of ctrl-shift-f9. Consider working with a large spreadsheat with hundreds of numbers. It's virtually impossible to even know if some numbers are stale or not: the very reason why a spreadsheat application was used in fist place is to not calculate manually. It took me a while to recognize that same of the data shown in my statistics document were wrong, and at least scared me quite a lot that I cannot 100% trust the numbers I see. Anyway, just wanted to put things in perspective.
> You're only speaking as a dev here... As an ordinary user I have never heard > of ctrl-shift-f9. Ehm..unfortunately I'm also an ordinary user, not a dev. And I'm also happy to see this bug resolved :) But we just tried to follow the triaging procedure. Many bugs have more critical importance, like crash & case without any workarounds. You can see hard recalc in offline help with search term: recalculating. It's shown also as shortcut key in Tools > Customize > Keyboard Anyway..I agree with you that we should have the workaround well documented so everyone could see easily. > ... It took me a while to recognize that same of the data > shown in my statistics document were wrong, and at least scared me quite a > lot that I cannot 100% trust the numbers I see. Anyway, just wanted to put > things in perspective. I also understand the situation, so we put that importance "high major" right? Not default medium normal..
*** Bug 80957 has been marked as a duplicate of this bug. ***
*** Bug 81099 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > Reproduced with LO 4.3.0.2, 4.2.5.2, 4.2.0.0.beta1 - Ubuntu 12.04 x86 > Hard recalc (ctrl-shift-f9) solves the problem > > Not reproduced with LO 4.1.6.2 Not reproduced also with 4.2.4.2
(In reply to comment #4) > But we just tried to follow the triaging procedure. Many bugs have more > critical importance, like crash & case without any workarounds. > But we just tried to follow the triaging procedure. Many bugs have more > critical importance, like crash & case without any workarounds. Please define "Critical Importance"! I don't check every single bug or fix appearing on the dev ML, but for some reason this caught my attention. I recently submitted a quotation for a sizable project, based on calculations made in a complex Calc 4.2.5.2 spreadsheet and the client happily accepted. While reading this bug report I recalled having made a couple similar deletions in my spreadsheet. Having applied your workaround "kluge" to my spreadsheet, I discover that my quotation was 1,000 Euros (around US$ 1,350) below the nearest competitor's offer. Since you do not consider this bug to be of what you dismissively describe as "NOT Critically Important", then please contact me by PM and we can arrange for you to transfer this (non-critical) loss from your bank account to mine. Your measure of "Critical Importance" being "like crash & case without any workarounds" is only half correct. Ask yourself why we care if LO crashes or not and you will probably answer something to effect that "Users will lose confidence in the software and stop using it". Likewise, if users cannot trust LO to perform as we say it will, they will lose confidence in the software and stop using it, which means that we have all been wasting our time.
Hi Dave.. Maybe I was wrong setting the importance. Feel free to correct that according to this documentation: https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg I don't understand why I have to responsible about your commercial project regarding this software. May I missed something, we all know about general disclaimer to all open source software which we can read in the following (sec 6): http://www.libreoffice.org/about-us/licenses/ Looks like you need an office software with (some/limited) warranty & support, may I suggest you to consider one of the following alternatives: https://libreoffice-from-collabora.com/product/ http://office.microsoft.com/en-001/buy-microsoft-office-2013-suites-and-office-365-subscriptions-FX102886268.aspx http://www.kingsoftstore.com/software/professional-office-suite
Bug in LibreOffice 4.2.5.2, Windows 7 x64 Reproduce: 1. Create new Calc document 2. insert many figures on cells A1:A5 3. insert sum(A1:A5) function on cell A6 3. delete figure on cell A3 4. note that cell A6 update de SUM as expected 6. click the undo button 7. the SUM on A6 will not update any more Correct undo button behavior on LibreOffice 4.2.4
(In reply to comment #9) > Maybe I was wrong setting the importance. Feel free to correct that > according to this documentation: > https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart. > jpg Technically correct, but not the only yardstick to measure importance by. > I don't understand why I have to responsible about your commercial project > regarding this software. May I missed something, we all know about general > disclaimer to all open source software which we can read in the following > (sec 6): http://www.libreoffice.org/about-us/licenses/ Oh calm down! I should have added a ;) smiley to indicate it was a joke. > Looks like you need an office software with (some/limited) warranty & > support, may I suggest you to consider one of the following alternatives: Please do NOT lecture me about what I need. :( I have been compiling this software and adding my own patches almost from the day Sun open sourced the code. Probably before you even knew OpenOffice.org existed. In recent times other commitments have not allowed me to do this. If I can find the time I will pull the code and submit a patch, maybe in time for 4.3.1, 4.3.2
(In reply to comment #11) It's ok Dave.. :) Time to prove that you're a senior here ;) Btw I think no loss for me if I don't contribute anymore to triage bug here if you find me have less qualification, since I also realized I have made many mistakes while triaging.
Bug also present on the next versions: tested on LibreOffice 4.2.6.1 tested on LibreOffice 4.3.0.1
Duplicate to Bug 80062 I think.. I forgot to inform, saving & reopening file after undo will also force hard recalc. Cell content not missing *** This bug has been marked as a duplicate of bug 80062 ***
Hi, this bug contains more infomation and is on MAB4.2 list,so I think it's better to set bug 80062 as duplicate of this one.
*** Bug 80062 has been marked as a duplicate of this bug. ***
*** Bug 81559 has been marked as a duplicate of this bug. ***
I have also experienced this bug, both on my PC running Windows 7 and my Mac, running OS X Mavericks. I had to go back to version 4.2.4, where I will stay until this particular bug is fixed.
Setting to NEW - REOPENED is only if the bug has been fixed by a developer and currently assigned.
d1be95a1c07cbea84230b40789a4fae867ef20c4 is the first bad commit commit d1be95a1c07cbea84230b40789a4fae867ef20c4 Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Tue May 20 12:51:51 2014 +0000 source-hash-26946775d73ee0b4f8fd3effa37549f463fde6db commit 26946775d73ee0b4f8fd3effa37549f463fde6db Author: Miklos Vajna <vmiklos@collabora.co.uk> AuthorDate: Sat May 3 20:53:02 2014 +0200 Commit: Miklos Vajna <vmiklos@collabora.co.uk> CommitDate: Sat May 3 21:11:03 2014 +0200 coverity#1078575 Unchecked dynamic_cast Change-Id: Ie25c91ce0035c78629ebd8466baa717d62948503 :100644 100644 1315213d62e9db779916ce48371a89fa31867b0b a1b03fc9a21105c4e91cf252040c57e60f63caf2 M ccache.log :100644 100644 9c728d68efbe36be265f19b9a78f9d6280176e98 8730cebcd4c066dce3a134e5dce281faae5e6d09 M commitmsg :100644 100644 58e54f9015582d37978cd75e1ebdaed7ba12ea8f 16759c12474f802446b6cad8937b61086eb775a5 M make.log :040000 040000 8236eb41fc03f7f798cda8f31383bf2087db52e9 f1c04ecc010ae3f70f307a0dae92d61530cfbbd3 M opt git bisect log # bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e # good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 git bisect start 'latest' 'oldest' # good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574 # good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d # good: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07 git bisect good a900e72b6357882284c5955bdf939bf14269f5fb # skip: [e80660c5a1d812cd04586dae1f22767fc3778c4a] source-hash-07c60c8ee2d1465544a6a39e57bc06b3690b8dfb git bisect skip e80660c5a1d812cd04586dae1f22767fc3778c4a # good: [df9bcaed2faa2a8d11b19f877cdff3a12a887278] source-hash-6ba9692d8bbe3e3c245aca9a7c928e81178d05f1 git bisect good df9bcaed2faa2a8d11b19f877cdff3a12a887278 # good: [741197a13a361480f59eeb3bd1401f984f49f1c0] source-hash-9a61470eb1fa161cba70f2e9c4ea8817dc7f617e git bisect good 741197a13a361480f59eeb3bd1401f984f49f1c0 # bad: [882db5e268e28962bdf805c820a5e031b0df9936] source-hash-383dccc094f8c8c07b4298ce0b7406d18cd61cee git bisect bad 882db5e268e28962bdf805c820a5e031b0df9936 # bad: [17f897f0e3734070f0e5c6abd39f2f907f42ac86] source-hash-4041263bde64dcc9a9a225d7f5a171f3b0455724 git bisect bad 17f897f0e3734070f0e5c6abd39f2f907f42ac86 # skip: [a79f817930f3cec0a793e0c5f4d0ffbb9737ac3a] source-hash-e8288b8857928cb54077608ca5907c966bfd490f git bisect skip a79f817930f3cec0a793e0c5f4d0ffbb9737ac3a # skip: [f959d021204b91b8ee86f06e3e1325187f5c8da5] source-hash-290ecbca8dfbe1edfdf5f305e2da652cf0f60bd8 git bisect skip f959d021204b91b8ee86f06e3e1325187f5c8da5 # bad: [d1be95a1c07cbea84230b40789a4fae867ef20c4] source-hash-26946775d73ee0b4f8fd3effa37549f463fde6db git bisect bad d1be95a1c07cbea84230b40789a4fae867ef20c4 # good: [1de992ed60dad1fd65ff0383a8610b0468d9d772] source-hash-8bf0b9536cb33dfcce8a811b70c2ead285300f3f git bisect good 1de992ed60dad1fd65ff0383a8610b0468d9d772 # first bad commit: [d1be95a1c07cbea84230b40789a4fae867ef20c4] source-hash-26946775d73ee0b4f8fd3effa37549f463fde6db
Crap! I fixed this one and it came back again!?
(In reply to comment #21) > Crap! I fixed this one and it came back again!? This bug is similar to the one you solved but maybe not the same: https://bugs.freedesktop.org/show_bug.cgi?id=74014 After reading comments from 33 to 37 (between me and ign_christian) this bug looks a bit different.
sigh
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2ef608aa35ee50a271ba817ef1538e663b4e0cae fdo#80846: Write test for this. 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.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1fcc30503549b47046c84333af542ed739f685ba fdo#80846: Get the parameter order right. 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.
Fixed on master, backports to 4.2 and 4.3 on the way.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b50f1343fb51baf244761c424f3bb64be8125e42&h=libreoffice-4-2 fdo#80846: Get the parameter order right. It will be available in LibreOffice 4.2.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.
Kohei Yoshida committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea67eca2ab1e3780551eadfa2d694bbd528d8ce4&h=libreoffice-4-3 fdo#80846: Get the parameter order right. It will be available in LibreOffice 4.3.1. 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.
*** Bug 82295 has been marked as a duplicate of this bug. ***
Open Office Calc F9 ReCalc Ctrl-Shift-F9 Hard ReCalc Enter data in a cell, ref this cell either directly or via a formula. Delete the data and the calculated cell shows '0'. Now Undo to reverse the Delete, the data is restored but the cell with the formula stays at '0'. Results for different versions: v4.3.2.0.0+ ReCalc - F9 Yes Ctrl-Shift-F9 Yes v4.3.0.4 Has the bug described above F9 No Ctrl-Shift-F9 Yes v4.2.7.0.0+ Has the bug described above F9 Yes Ctrl-Shift-F9 Yes v4.2.5.2 Has the bug described above F9 No Ctrl-Shift-F9 Yes v4.2.5.1 Has the bug described above F9 No Ctrl-Shift-F9 Yes v4.2.4.2 The above bug is not encountered v4.2.4.1 The above bug is not encountered v4.1.5.3 The above bug is not encountered v4.1.4.2 The above bug is not encountered
*** Bug 82862 has been marked as a duplicate of this bug. ***
I update from 4.3.0.3 to 4.3.1.2 and the bug continues LibreOffice 4.3.1.2 PT_pt, Windows 7 64Bits PT_pt
Created attachment 105442 [details] Picture of bug
Following bug description, confirm bug still exist under Ubuntu 12.04 x86 with: - LO 4.3.1.2 - LO 4.3.2.0.0+ Time: 2014-08-29_03:57:12 - LO 4.2.7.0.0+ Time: 2014-08-29_05:39:56
*** Bug 83553 has been marked as a duplicate of this bug. ***
*** Bug 83434 has been marked as a duplicate of this bug. ***
Wrong Behavior remain on LibreOffice 4.3.1 (Windows 7)
*** Bug 83993 has been marked as a duplicate of this bug. ***
Wrong Behavior FOR REPORTER#S PROCEEDING remain on LibreOffice Version: 4.4.0.0.alpha0+ Build ID: 0b3b907e96a8bbc477b8755a5bcffc350c53ce2b TinderBox: Win-x86@39, Branch:master, Time: 2014-09-16_05:01:30
While looking through the bug fixes made for the version 4.2.5, I found this fix (bug 74687) which seems to be related to the current bug since it added a condition to the broadcast when performing an "UNDO" and an "REDO". Maybe a flag is missing or the change is not properly flagged. I didn't know if this could help but I wanted, at least, to share my "discovery". Take care!
This bug is highly critical, like any bug that might make a wrong result in one cell ! If 'Hard recalc (ctrl-shift-f9)' solves the problem, then is it possible to quickly program a hard recalc into undo procedure. Something like : |Sub Undo_procedure() | ... | 'something about Undo code... | ... | | Call Hard_recalc() ' yeah ! | |End Sub You won't find the bug, but my Spreadsheet result will be right. Thank you for all the job ! Have a nice day, Laurent
*** Bug 84174 has been marked as a duplicate of this bug. ***
*** Bug 84420 has been marked as a duplicate of this bug. ***
Confirmed as not resolved - another dupe found and confirmed on 4.4 built a few days ago.
*** Bug 84798 has been marked as a duplicate of this bug. ***
This was reported 2014-07-03. It's now 2014-10-08. So over 3 months! Are there really bugs more important than this? It makes me wonder what foul problem I've been lucky to miss so far. I won't use LO if I can't trust the numbers on the screen. Telling me to 'hard recalc' is pathetic. When I should I do that? Every time I change any cell??? I'm going back to v4.2.4.2. Which means I miss all those other fixes... but this one is, for me, CRITICAL
@Toby - that comment is literally 100% useless and does not help AT ALL in resolving the issue. In the future please keep in mind that we're a team of VOLUNTEERS - having others tell us what to do with our time and how to prioritize our time is bound to not make friends in the community. Feel free to submit a patch yourself - the code is readily available.
@Joel You're right. I apologise for loosing my temper. I would delete my comment if I could work out how. I understand that, technically, this is not a critical bug, in that it does not crash the system. However if the numbers on the screen are wrong, then LO is failing at a fundamental level. It's core functionality doesn't work. It's unusable. And that means it's a 'blocker'. You may also say this comment is 100% useless, as it doesn't help fix the bug. Again, technically, you're right. But it's the only avenue I have of attempting to alert someone with the power to 'upgrade' this bug of it's severity. I don't mind bugs. I've lived with the 'disappearing filter' problem for months. But I won't live with this. Could you tell me how to download v4.2.4.2 please (as it doesn't have this bug)? Otherwise I'll have to go to OO.
Thanks for the apologies. That being said, let me clarify something that you appear not to understand. There is literally NO ONE who can "upgrade the bug" - we don't dictate to our VOLUNTEERS what to fix. Really, I am not lying, there is not one single individual in the entire project who can "upgrade the importance" and thus force someone else to fix it. Even if we set it to "blocker" the same result would occur - a volunteer would have to VOLUNTARILY fix the issue. The Document Foundation has ZERO paid developers. So the options: 1) Use an older version until it's resolved; 2) Submit a patch yourself; 3) Pay for a fix; 4) find a friend or family or some other person that you know of to fix it; 5) wait patiently for a fix. These are the only options. We're a community, we're all in it together, and we're all in the same position. This bug is on the MAB list, Kohei who is one of our most talented developers is well aware of the issue, there are now quite a few duplicates, trust me, the issue is known.
@joel I understand that nobody can force someone to work on this. However it should be rated as a blocker so that anyone sorting by importance (that's what it's labelled as) would see it somewhere near the top. I've done that. I already asked you how to download v4.2.4.2 as it's not available on the website. I found it at: https://downloadarchive.documentfoundation.org/libreoffice/old/4.2.4.2/win/x86/LibreOffice_4.2.4.2_Win_x86.msi
This is not a blocker - please don't change it back. https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
"loss of data"
Actually by "loss of data" you probably mean data on HDD How about "broken core functions"? I won't use anything later than v4.2.4.2 because I can't trust the numbers. That's pretty broken. Anyway... you say it's a known issue and on the 'MAB' list, so I'll just wait until it's fixed to upgrade.
Dear volunteers, I apologise about adding useless to useless, but I would like to confirm Toby's despair (comment 46) : our lovely software has a severe bug which makes it seriously doubtful, dangerous, useless. For my point of view, according to https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg, this bug seems to be a blocker • Is bug cause loss of data ? yes, definitively yes. • Does this bug happen very frequently ? Yes, every time user types 'Ctrl Z' Sorry again to cry without suggesting anything (I tried to propose something -stupid ?-, please see comment 41), I hope you will find quickly a solution. Have a nice day, Laurent
I highly recommend every person who has commented on this bug to get involved with QA. Please come say hello and volunteer like hundreds of others do - it's only through collaboration (not through spamming the bug report) that we can ensure that LibreOffice continues to improve for everyone. Come say hello, we're quite friendly and have more than enough tasks to need lots and lots of new volunteers. Chat: http://webchat.freenode.net/?channels=libreoffice-qa
(In reply to Rui Simoes from comment #33) > Created attachment 105442 [details] > Picture of bug The problem with SUM() function is different from the bug described in this bug report. Indeed the scenario in the description of the bug works as expected in LO 4.3.3.0.0+ and the master and the scenario in comment #10 with the SUM() function is still broken. Please confirm, close this one again and open a separated bug report from comment #10 (or reopen the bug report wrongly marked as duplicate if it exist). Best regards. JBF
*** Bug 84850 has been marked as a duplicate of this bug. ***
FYI http://cgit.freedesktop.org/libreoffice/core/commit/?id=424bfaa773e58d6b609ac7f64907db4b542d1315
Hey Kohei - Is that a fix or a code pointer? Thanks for the hard work :)
It's a potential fix. It would be nice to get it verified.
For 4.3: https://gerrit.libreoffice.org/11927
I'll mark it FIXED in the meantime. Let's see if it will stay that way.
(In reply to Kohei Yoshida from comment #62) > I'll mark it FIXED in the meantime. Let's see if it will stay that way. Yes! Both cases, description and comment #10, work as expected. Tested with Version: 4.4.0.0.alpha0+ Build ID: 6ba7f47de32074895b830e1ef3682fa1d0d1b6be built at home under Ubuntu 14.04 x86-64. Thank you very much. Best regards. JBF
*** Bug 78694 has been marked as a duplicate of this bug. ***
http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-4-3&id=eb5f25984307cd9e63e9cc88cbdb09228d66b097
Will it be backported in the 4.2 branch? I know it's too late for the 4.2.7 but I noticed, in the daily build page, that there is a 4.2.8 ongoing. If it's possible, it would be appreciated! Thanks
*** Bug 87087 has been marked as a duplicate of this bug. ***
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]