[Libreoffice-bugs] [Bug 142556] New: FILEOPEN, EDITING, Cell with syntax ==IF() displays a result, no error, corrupts calculations and user profile

Sat May 29 11:22:17 UTC 2021

https://bugs.documentfoundation.org/show_bug.cgi?id=142556

            Bug ID: 142556
           Summary: FILEOPEN, EDITING, Cell with syntax ==IF() displays a
                    result, no error, corrupts calculations and user
                    profile
           Product: LibreOffice
           Version: 4.3.0.4 release
          Hardware: All
                OS: Windows (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Calc
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: matthewnote at yahoo.co.uk

Description:
A large file gives four different results for column data range values and
corresponding x,y scatter diagrams.  Options for Java runtime produce different
values.  Closing (without saving) and reopening the file produces different
results (after User Profile has been modified automatically).  Reset User
Profile changes the results also, without improvement.  "Delete then
Undo:delete" behaves differently than "delete then re-enter" or "paste new
values".  For Windows,Option OpenCL disallowed evades/avoids the symptoms.  The
provocation is found to be one cell syntax ==IF (without operands, without
dependents, without error label for the user, showing a value not used
elsewhere). Finding (difficult) and correcting (easy) this cell to =IF resolves
the derangement.  Investigation continues to check for file damage (if saved)
or if the User Profile changes need to be purged or both.

Steps to Reproduce:
1. Close actual work with Libreoffice (Writer or Calc)or restart computer.
2. Windows, OpenCL allowed. Start Calc but do not open any other file.
3. Open the attachment file syntax ==
4. Use mouse to Select H19 to L19. Those cells are now highlighted.
5. Use keyboard delete key to empty those cell values.
6. Charts in red and orange update correctly.
7. Use mouse (important) toolbar "back arrow" to "Undo:delete".
8. The red chart x values are restored, but the y values not (incorrect)
9. Mouse click Data>Calculate>Recalculate hard, the chart updates x values.
10. Edit cell L23 (blue) from ==IF to =IF.  Save file under new name.
11. Restart Calc, open new file
12. Repeat steps 4 to 7. "Undo:delete" now causes correct chart update.

Actual Results:
Cell L23 is without dependents but Calc interprets ==IF (with many more
consequences than those described above using only a reduced version of the
original file).  A User Profile change occurs also that may be a new corruption
(to be confirmed). Seeing or not seeing the problem is configuration dependent.

Expected Results:
Boolean Equality == is a valid operator (Javascript also) yet requires two
operands.  Expected result were Calc sets Err:502 invalid argument.

Reproducible: Always

User Profile Reset: Yes

Additional Info:
Only Windows tested so far (Ubuntu version work in progress).
The red graph in step 8 error state shows most points value -27.  
This PC here has Options>Advanced>Java Runtime enabled by default, JRE empty.
If Java runtime is disabled, the red graph error state shows points at value 0.

Disabling OpenCL, repeating all steps, the fault is hidden (manipulations run,
data ranges update, charts update) even though the == syntax is still there.

The sample file is a small extraction from a very large file.  The syntax
problem was very difficult to find (only one cell and only checking by eye) and
repositionned at L23 deliberately for simplicity.

Although this Calc vulnerability may seem simple to close (therefore minor),
the consequences for the file/autocalculate were very difficult and a severe
challenge.  I find (so far) that re-using the original file (used in Bug 86321)
there are at least three different states at Open, depending on the User
Profile situation and work flow. Copy the values and paste behaves differently
to Undo:delete in some cases.  Before Chart updates fixes this month, this was
nearly impossible to diagnose. I'll file a different Bug report about the
sporadic fail aspect (where and how).

Was the file damaged in xml in any way?  Seems not;  work in progress.
How does Ubuntu+Calc react?  Not sure; my OpenCL plus Linux fails test, so off.
Are there any other operators causing same type of bug?  Work in progress.
Earliest affected version?  Unknown, so reported using the first version known
to generate the file that was master file for this new reduced sample.

Always reproduceable on:
Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 1675a68526c43c6c6e4dc850ee911f0c1de75c88
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: nl-NL
Calc: CL

Version: 7.1.3.2 (x64) / LibreOffice Community
Build ID: 47f78053abe362b9384784d31a6e56f8511eb1c1
CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: da-DK (da_DK); UI: da-DK
Calc: CL

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210529/4a9784a1/attachment.htm>