Enter in a cell : '(/21) (Note the ' sign). In this same cell, replace this content by a formula as =SUM(A1:A2) We get : 5 for example, if the sum of A1:A2 is 5. Type Ctrl-z. The content of the cell is now : -21 Expected : the content of the cell should be : '(/21)
Reproducible. Win10x64 Version: 5.2.3.1 (x64) Build ID: 01ec8f357e651ca9656837b783cf7e6a32ee4d92 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Locale: es-ES (es_ES); Calc: CL Version: 5.3.0.0.alpha0+ Build ID: ed5ca17dce1d088ce3fbbb3a30f748ba92cd07d9 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-10-09_05:40:51 Locale: es-ES (es_ES); Calc: CL
works ok in 3.3.0.4 > regression
works ok in 4.0.6.2.2 not in 4.1.0.4.
Working in the 43max bibisect repository on debian-stretch, I see from `git bisect good` (lines rewrapped) ... 74b89c3193673ba9897dc4a4541500ef6e8d9bf7 is the first bad commit commit 74b89c3193673ba9897dc4a4541500ef6e8d9bf7 Author: Matthew Francis <mjay.francis@gmail.com> Date: Thu May 28 21:58:44 2015 +0800 source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 commit 8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 Author: Stephan Bergmann <sbergman@redhat.com> AuthorDate: Wed May 21 18:22:27 2014 +0200 Commit: Stephan Bergmann <sbergman@redhat.com> CommitDate: Wed May 21 18:29:57 2014 +0200 So ZCodec::ReadAsynchron was wrong in using a persistent mpIStm after all The fun thing is that with the (only) call-site to ReadAsynchron in PNGReaderImpl::ImplReadIDAT (vcl/source/gdi/pngread.cxx) passing in rIStm references to stack-allocated SvMemoryStream instances, mpIStm could point to an old, destroyed instance from a previous call, but which would have been located at exactly the same stack address as the currently passed in rIStm, so the wrong mpIStm->Read call would effectively behaved exactly the same as a correct rIStm.Read call. This went unnoticed "since the beginning" until AddressSanitizer's UseAfterReturn check came along... Change-Id: I7c75ed2d36a4c24c111d88eff647816bd2c5dbca :040000 040000 213905d77803f5109a8eb9d508a99dea4b78a423 fb17ca372d0bfc007a2482860c18bb9c09b06e4c M opt and from `git bisect log` (whitespace added) ... # bad: [74b89c3193673ba9897dc4a4541500ef6e8d9bf7] source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 # good: [9c392cfdfe6e9a9bce98555ea989283a957aa3ad] source-hash-fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3 git bisect start 'latest' 'oldest' # good: [e289d9d328719fd70e9a2680fd0e4f586a97b3be] source-hash-3c0a7cf4f67720f2cca2c4eb543f838d5b644e7f git bisect good e289d9d328719fd70e9a2680fd0e4f586a97b3be # good: [3e807472869ed7d72b026c12cd1e7c3cb990591f] source-hash-6390dd9777ff63ca75a088e56dd444a355439343 git bisect good 3e807472869ed7d72b026c12cd1e7c3cb990591f # good: [badf3854a52f4805b58cb5d82c7f5008bb08d70e] source-hash-a911f866623db7a03b12f0143df8d54a95805581 git bisect good badf3854a52f4805b58cb5d82c7f5008bb08d70e # good: [f68a3ffd75febb1be3f68d578bba9d65d43317e6] source-hash-34509a0805d408cd45c1b95f5afdafdc46c1501e git bisect good f68a3ffd75febb1be3f68d578bba9d65d43317e6 # good: [979807345606fff7e86f0607844bf5b46d889320] source-hash-a4f32eec653596483088c6e5aa37de031278d74c git bisect good 979807345606fff7e86f0607844bf5b46d889320 # good: [cf73c50a38c18a713cdc9acb5301df4772e385a1] source-hash-85500add33b7cdb647b61c83aa6b84a94f3b98a1 git bisect good cf73c50a38c18a713cdc9acb5301df4772e385a1 # good: [d35a3d743fd4ce77f26692deede22f07e4a6454e] source-hash-498c314861f0913a5b31ee29efc38aad12c3a781 git bisect good d35a3d743fd4ce77f26692deede22f07e4a6454e # good: [024013f04784fedda4fd73d5dc88d1bf68b8ce3a] source-hash-f824604b5c1b480bf6680935362eb1d4617187c9 git bisect good 024013f04784fedda4fd73d5dc88d1bf68b8ce3a # skip: [97e78b341123efc954722159d9825428b1a8eebe] source-hash-2993c7c0000d32933bc7ca7fabe975a91b672edf git bisect skip 97e78b341123efc954722159d9825428b1a8eebe # good: [b1cde3a22afb63b3b0c4f0dda2dce874d2419744] source-hash-4d2113250fa7ed62fe2c53ed0f76e3de5875cb81 git bisect good b1cde3a22afb63b3b0c4f0dda2dce874d2419744 # good: [ed46573bbbd30ce78fbff19049cc7e5f0680e87c] source-hash-d4af55670fa1f2653e4a64031cc09d51b5ccc8f6 git bisect good ed46573bbbd30ce78fbff19049cc7e5f0680e87c # good: [bd497590535f2a363ffb2ea1e9d7edddca781aa3] source-hash-a95d12b547e2635e10aa074fe42f12a0ea151163 git bisect good bd497590535f2a363ffb2ea1e9d7edddca781aa3 # good: [ce19c7c6a2254400aa0f5c5c3c0704d3df39a6ed] source-hash-34f0e4f42594adb97bdb64e5f2e8f00801b48e2e git bisect good ce19c7c6a2254400aa0f5c5c3c0704d3df39a6ed # good: [1107e077b38c2a3c1942ece5c77d8a05a389bf31] source-hash-c5a603ce2469ef6a23023ff276ccd24ca316f6c2 git bisect good 1107e077b38c2a3c1942ece5c77d8a05a389bf31 # first bad commit: [74b89c3193673ba9897dc4a4541500ef6e8d9bf7] source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 I am removing keyword bibisectRequest and adding bisected.
Adding Cc: to Stephan Bergmann
(In reply to Terrence Enger from comment #4) > Working in the 43max bibisect repository on debian-stretch, I see from > `git bisect good` (lines rewrapped) ... > > 74b89c3193673ba9897dc4a4541500ef6e8d9bf7 is the first bad commit > commit 74b89c3193673ba9897dc4a4541500ef6e8d9bf7 > Author: Matthew Francis <mjay.francis@gmail.com> > Date: Thu May 28 21:58:44 2015 +0800 > > source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 > > commit 8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 > Author: Stephan Bergmann <sbergman@redhat.com> > AuthorDate: Wed May 21 18:22:27 2014 +0200 > Commit: Stephan Bergmann <sbergman@redhat.com> > CommitDate: Wed May 21 18:29:57 2014 +0200 > > So ZCodec::ReadAsynchron was wrong in using a persistent > mpIStm after all I cannot reproduce your findings: * I can reproduce the original problem with a recent local master build. * I can still reproduce the problem when locally reverting the above commit 8f97326bdd3f42fc82aa5e1989fd03b0af1daf64 in that local master build. (Which makes it even less likely that that commit is the culprit than it already looked from the commit's content.) * Installing <http://dev-downloads.libreoffice.org/bibisect/linux/bibisect-43max.tar.xz>, I can not reproduce the problem with any of the included builds that I sampled: ** Not with the earliest build included, 9c392cfdfe6e9a9bce98555ea989283a957aa3ad "http://dev-downloads.libreoffice.org/bibisect/linux/bibisect-43max.tar.xz". ** Not with the alleged culprit, 74b89c3193673ba9897dc4a4541500ef6e8d9bf7 "source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64". ** Not with the latest build included, 74b89c3193673ba9897dc4a4541500ef6e8d9bf7 "source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64".
Stephan, I apologize for the noise in my comment 4. Here, I am trying again, and I add Caolán McNamara to cc. Working in the 44max bibisect repository, I see from `git bisect bad` (whitespace added and lines rewrapped) ... c29a8309369895707096e16ca67d0bf1d7a82f68 is the first bad commit commit c29a8309369895707096e16ca67d0bf1d7a82f68 Author: Matthew Francis <mjay.francis@gmail.com> Date: Sun Mar 15 04:29:24 2015 +0800 source-hash-e0108fa4fc954f39ef56b841dceb6a2d27d5618c commit e0108fa4fc954f39ef56b841dceb6a2d27d5618c Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Fri Oct 24 12:51:33 2014 +0100 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Fri Oct 24 13:43:10 2014 +0100 make Korean ReplaceSingleQuote the same as everyone else I can find no evidence that Korean out of all languages on earth needs a different default for ReplaceSingleQuote This appeared in commit e9f10288e0e5f2519ff3da1e2de2c20a99fd9779 Date: Mon Jul 5 12:32:15 2004 +0000 2004/06/07 18:46:25 jb 1.14.78.1: #i25937# Add module settings (migrated from scp2) to xcu source files but that's a migration of the original GID_CONFIGURATIONITEM_SWRITER_KOREAN_ENABLE_SINGLEQUOTE which existed in the original scp (pre scp2) and appeared between OpenOffice.org 1.0 and 1.1.5, but the cvs repos to explain all that are long dead and there is no sign of a bug in a bugzilla query, so it suggests this was an internal StarOffice thing. Change-Id: I14dfe75d28d3ec5a68b262f768c7dbe73e94131d :040000 040000 d3f1567c6f1e73f148911934076400abbf632d23 76c955be58e0bb4780e40b49f48ed5356da3d778 M opt and from `git bisect log` (lines rewrapped) ... # bad: [cf6ea17155fabb2a120ba07c150735591ac861d7] source-hash-3f94c9e9ddfd807b449f3bb9b232cf2041fa12d2 # good: [fc71ac001f16209654d15ef8c1c4018aa55769f5] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e git bisect start 'latest' 'oldest' # good: [8cf60cc706948588e2f33a6d98b7c55d454e362a] source-hash-f340f0454627939f1830826fb5cc53a90e6c62a4 git bisect good 8cf60cc706948588e2f33a6d98b7c55d454e362a # good: [7beddf3808dadd525d7e55c00a5a90a2b44c23d3] source-hash-2f10386ce577f52e139aa23d41bc787d8e0b4d59 git bisect good 7beddf3808dadd525d7e55c00a5a90a2b44c23d3 # bad: [fb3ec529b3f37f0c7eab2e9b7a9cc695c0f27676] source-hash-0516d123f53917d1833c7e8a8c528a619c71a0af git bisect bad fb3ec529b3f37f0c7eab2e9b7a9cc695c0f27676 # good: [74c2960deb8278b16021ff39bb8b8b58fa887351] source-hash-d4867ddae67def9a52d7e3e027e261323f32c8f9 git bisect good 74c2960deb8278b16021ff39bb8b8b58fa887351 # bad: [fa3c391991dca0f1e8e3db8393f3564625959ce4] source-hash-3bdee6495ebc7f515d6d297e7f7df9a46acc3880 git bisect bad fa3c391991dca0f1e8e3db8393f3564625959ce4 # bad: [e39d1b31e6bc92451823f0c9445b77ed32eac06c] source-hash-91fac2a32c1c6b784bd33cf664ea64a734b1c776 git bisect bad e39d1b31e6bc92451823f0c9445b77ed32eac06c # bad: [094c0417c254726980d57aa8690d36cecb1d466b] source-hash-94a1e5b614496fd067e2c5369613acf86a6c9a6d git bisect bad 094c0417c254726980d57aa8690d36cecb1d466b # good: [92647c42b4697966537b278becb51701dfa3138c] source-hash-096452279717d2d13b6140fa80b1442a59e5e874 git bisect good 92647c42b4697966537b278becb51701dfa3138c # good: [e3d029b63ad721d1a7b92cec37def343444a35cf] source-hash-6d477b4b4a9d80eeb42cb771cc009bd03d3022d8 git bisect good e3d029b63ad721d1a7b92cec37def343444a35cf # good: [5ae43438860e84f178feaa3c6951faab048d6976] source-hash-7fd9b8268f87831e2728b5def34cc5e97ed16ab0 git bisect good 5ae43438860e84f178feaa3c6951faab048d6976 # bad: [26af963aee1ce32a8406e470aa830341801674eb] source-hash-e25a020d59b019893d2e04ac61e4ed25ef0a6e61 git bisect bad 26af963aee1ce32a8406e470aa830341801674eb # bad: [85c40a8172f405b2d7fcade3d410df83962200af] source-hash-5aebe7b67c02051cb4fe98219cfe056efaf975a1 git bisect bad 85c40a8172f405b2d7fcade3d410df83962200af # bad: [c29a8309369895707096e16ca67d0bf1d7a82f68] source-hash-e0108fa4fc954f39ef56b841dceb6a2d27d5618c git bisect bad c29a8309369895707096e16ca67d0bf1d7a82f68 # first bad commit: [c29a8309369895707096e16ca67d0bf1d7a82f68] source-hash-e0108fa4fc954f39ef56b841dceb6a2d27d5618c
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This issue is still present with LO Version: 5.4.3.2 Build ID: 92a7159f7e4af62137622921e809f8546db437e5 Threads CPU : 2; OS : Linux 4.9; UI Render : par défaut; VCL : gtk2; Locale : fr-FR (fr_FR.utf8); Calc: group
can reproduce with Version: 6.0.0.0.alpha1+ Build ID: dfc45f0abab98a1ce977c6ed95dfa07c185b6d11 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group
https://gerrit.libreoffice.org/#/c/45008/ is my take on fixing this
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=466c3564058aae4946cdd21eab9dfef529554d90 tdf#103234 undo replacing text with formula It will be available in 6.0.0. 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2f0a7c5a9d8185fedef5c737d1b7479b9fc0c1e Invert logic of ScSetStringParam::* enum value checks, tdf#103234 follow-up It will be available in 6.0.0. 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ba9833a1d63747eaa5124271a1ac51cb926bce7a Keep number format on string cell content Undo, tdf#103234 follow-up It will be available in 6.0.0. 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.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ad07d83af2a2b7df29223891bc028a4e7aedfe72&h=libreoffice-5-4 Resolves: tdf#103234 undo replacing text with formula It will be available in 5.4.4. 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.
tested and its working with Version: 6.0.0.0.alpha1+ Build ID: f1a55c4bfc6afcd9fd316e055e626097e0666ea8 CPU threads: 8; OS: Linux 4.14; UI render: default; VCL: kde4; Locale: nl-BE (en_US.UTF-8); Calc: group threaded