TLDR: Bug 123752 is back. I don't know if 7.0.3.1 is the first version to exhibit this, it's just what I updated to from 6.4.7.2. This is a regression with a possibility of data corruption. This affects locales where the grouping separator is not a comma or an apostrophe. Steps to reproduce: 1) use a locale like fi_FI or fr_FR for the document 2) enter a value like 12345,67 into a worksheet cell 3) pick a number format like "# ##0,00" for the cell 4) copy the cell to clipboard 5) enter another cell, type a starting = and paste The result is Err:509 in the target cell and the pasted value has an extra zero before the decimal separator, i.e. =123450,67 If the worksheet with such an error is closed and then reopened, the error status gets cleared but the value in the target cell is the one with an extra zero. Commit c4eb7dddf047 which fixed it the last time is still part of the codebase so the breakage comes from somewhere else.
$ git bisect bad 789b761baf6af11e78a3933bd117666e5efb89c3 is the first bad commit commit 789b761baf6af11e78a3933bd117666e5efb89c3 Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Sep 30 14:36:22 2020 +0200 source 30d3ae0268290e6244e58c78b8f45ae7373c47ea source 30d3ae0268290e6244e58c78b8f45ae7373c47ea instdir/program/libforlo.so | Bin 368896 -> 369384 bytes instdir/program/libsclo.so | Bin 22199528 -> 22199744 bytes instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- 4 files changed, 2 insertions(+), 2 deletions(-) git bisect start 'latest' 'oldest' # good: [37ce4f45d3e97a9ca075929c9eaa57f5b0104abd] source ee78313613605f50795d8ba0fbcd4138c9845a51 git bisect good 37ce4f45d3e97a9ca075929c9eaa57f5b0104abd # good: [a3d3fefa65f23c26716600421a06a471e4cba5ab] source fe98579520ebf3b570dc9f93451d7928769e4c43 git bisect good a3d3fefa65f23c26716600421a06a471e4cba5ab # good: [bb685ba59100ae0270db9df586e56951ccfa4e94] source 02b577f2f2f8bfea144ad156a55eec6e2b06ad7b git bisect good bb685ba59100ae0270db9df586e56951ccfa4e94 # good: [3611d8a4729ed43c14396da14c434f304b2b44e0] source 2d2d9e65104f0d6a1ebaed69fa604905be401438 git bisect good 3611d8a4729ed43c14396da14c434f304b2b44e0 # good: [f516a249697971b804438a6274cd34acb150dcf3] source e48eb426bbef20b9f5646d3fe3978a6f476be5cb git bisect good f516a249697971b804438a6274cd34acb150dcf3 # bad: [2d341371f724928088c76219df37adb9a6b93498] source e3c2dcceb0e885a5a2c76bb69eac6e2dbba98d6d git bisect bad 2d341371f724928088c76219df37adb9a6b93498 # good: [10f456c86656523b5645b1c46393b1742d92ff8e] source a77b7d720e454e66b8e6abe65b7cf49de4a6a6d3 git bisect good 10f456c86656523b5645b1c46393b1742d92ff8e # bad: [fc7c50679ab7d95b4a9b12b6296296429b806742] source 6eb7158e2b9049587f79e2225964ada1746bd83c git bisect bad fc7c50679ab7d95b4a9b12b6296296429b806742 # good: [837d822fe6ea8a6362499eff079187aa8640edf4] source 1208b154c44a4e930fc630e062273d91b21edb0a git bisect good 837d822fe6ea8a6362499eff079187aa8640edf4 # bad: [99bd0c18a8adaaeacb465bb362580a0f2a0bd61e] source 8d4d07e0c07120934706df03e777ac149c71e418 git bisect bad 99bd0c18a8adaaeacb465bb362580a0f2a0bd61e # good: [f3f5b0b33b2b7d6dbdf58e4124474270fee022ac] source 80e3ad82b1cfaa9e8de24cea6f118193d5a59621 git bisect good f3f5b0b33b2b7d6dbdf58e4124474270fee022ac # good: [3776c148d6ef536aef6c9fd0cd45c0a111e9b51e] source 831a9b465ac82ec8d27186329d6596ef5e9e4601 git bisect good 3776c148d6ef536aef6c9fd0cd45c0a111e9b51e # bad: [789b761baf6af11e78a3933bd117666e5efb89c3] source 30d3ae0268290e6244e58c78b8f45ae7373c47ea git bisect bad 789b761baf6af11e78a3933bd117666e5efb89c3 # first bad commit: [789b761baf6af11e78a3933bd117666e5efb89c3] source 30d3ae0268290e6244e58c78b8f45ae7373c47ea
Confirming now that a suite compiled from the 7.0.3.1 tarball with commit 30d3ae0268290e6244e58c78b8f45ae7373c47ea reverted does not have the problem. This of course breaks bug 137091 again though.
I do confirm the issue was introduced by: https://cgit.freedesktop.org/libreoffice/core/commit/?id=3c6177be2705303044e3de262689d593f3d0f282 author Eike Rathke <erack@redhat.com> 2020-09-28 21:02:23 +0200 committer Eike Rathke <erack@redhat.com> 2020-09-29 00:54:12 +0200 commit 3c6177be2705303044e3de262689d593f3d0f282 (patch) tree 0bef6428be1e46c48f5d58e5ccaefcfb500f5e9f parent 6e51adec109ab179f093181856959a6d8dc3d3b2 (diff) Resolves: tdf#137091 Use CharClass matching the formula language Bisected with: bibisect-linux64-7.1 Adding Cc: to Eike Rathke
Darn. Seems we need *three* locales in the compiler to be able to handle this, if possible at all.
Is this possibly being worked on? The code tree has changed enough between 7.0.5.2 and 7.1.3.2 that the patch I've used locally to revert the breaking change in 30d3ae0268290 no longer applies to sc/source/core/tool/compiler.cxx after all.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d703131d063c41b8baca01830c4c9806f99ab7d2 Resolves: tdf#138432 Use locale's CharClass to parse numeric i18n context It will be available in 7.3.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.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/c28ef94db9e4ba0a89ae66b0a38b27fbbb84e74e Resolves: tdf#138432 Use locale's CharClass to parse numeric i18n context It will be available in 7.2.0.0.beta2. 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.
Pending review https://gerrit.libreoffice.org/c/core/+/118190 for 7-1
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/c7d6a4dcfa82387d4ea2445b7af109101f0c365b Resolves: tdf#138432 Use locale's CharClass to parse numeric i18n context It will be available in 7.1.6. 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.
(In reply to Commit Notification from comment #9) > Affected users are encouraged to test the fix and report feedback. Patching the 7.1.4.2 source tree with commit c7d6a4dcfa does seem to produce a binary with the reported problem fixed. Thank you!
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-7-1-5": https://git.libreoffice.org/core/commit/a7d534639ce3dd6e18f349c33b2bcaa6b43a42a2 Resolves: tdf#138432 Use locale's CharClass to parse numeric i18n context It will be available in 7.1.5. 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.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/213430e0bdac0786b30a76a68b43d35647e93912 tdf#123752, tdf#138432: sc_uicalc: Add unittest It will be available in 7.3.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.