https://bugs.documentfoundation.org/show_bug.cgi?id=173843
Bug ID: 173843
Summary: Regression: nonrecursive LET formulas produce
stack-overflow errors with threaded calculation
Product: LibreOffice
Version: 27.2.0.0 alpha0+ master
Hardware: ARM
OS: macOS (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Calc
Assignee: [email protected]
Reporter: [email protected]
Created attachment 208901
--> https://bugs.documentfoundation.org/attachment.cgi?id=208901&action=edit
bug-repro.xlsx
Version: LibreOfficeDev 27.2.0.0.alpha0
Build: 3ca06ba1144a561e2eed2204d5407f71b063999a
Platform: macOS 27.0, Apple Silicon
I downloaded the alpha to try out the LAMBDA support, which seems to work
great.
But I also noticed that some of my old files were broken, unless I set
MAX_CONCURRENCY=1. So I made a minimal reproduction, showing that with normal
concurrency, the same file works fine on 26.8, but breaks on 27.2.
-- Steps to reproduce:
The attached workbook contains 16,384 rows. Column A alternates between 14 and
15; column B evaluates LET(v,A2,v+1), filled down. There is no recursion or
named function.
You'll see that towards the bottom, the values in column B start breaking.
Three threaded runs (headless conversions with fresh isolated profiles)
produced 7,094, 8,959 and 9,295 error cells. XLSX exports contain #N/A; direct
ODS exports expose native Err:514 (stack overflow).
If you repeat with multithreaded calculation disabled, or with threading
enabled and MAX_CONCURRENCY=1, all the values are fine. Stable LibreOffice
26.8.0.3 also passed three threaded runs without errors.
A debugger stopped in ScInterpreter::ScCall at the stack-overflow error branch
with the loaded callable-depth counter equal to 400, despite a shallow,
nonrecursive LET call stack. The development implementation uses an
unsynchronized document-wide counter, while LET remains eligible for threaded
calculation.
--
You are receiving this mail because:
You are the assignee for the bug.
