tdf#156677 if CheckComputeDependencies failed in expanded range...

it may have left a cell the original range needed in a dirty state,
leading to an assert when the threaded calculation is attempted which
would not have happened if the attempt to expand the range wasn't
attempted.

seen in crashtesting example: forum-mso-en4-784502.xlsx

to reproduce this, load sample document

after it has loaded:

(gdb) break column4.cxx:1946
(gdb) break column4.cxx:1966

data, recalculate, recalculate hard,

the first time breakpoint #1 gets hit:

at column4.cxx:1946 NeedsInterpret is true, so cell
{nRow = 1, nCol = 0, nTab = 3 } was dirty and is set
not-dirty by Interpret. mxGroup->mbPartOfCycle is false
so this returns successfully to allow threading.

the bt to there was:

#0  lcl_EvalDirty(mdds::mtv::soa::multi_type_vector<sc::CellStoreTraits>&, int, int, ScDocument&, boost::intrusive_ptr<ScFormulaCellGroup> const&, bool, bool, bool&, bool&)
(rCells=..., nRow1=1, nRow2=4, rDoc=..., mxGroup=..., bThreadingDepEval=true, bSkipRunning=false, bIsDirty=@0x7fffffff4a16: true, bAllowThreading=@0x7fffffff4a17: true)
at sc/source/core/data/column4.cxx:1963
#1  0x00007fff9eef70d1 in ScColumn::HandleRefArrayForParallelism(int, int, boost::intrusive_ptr<ScFormulaCellGroup> const&) (this=0x15ee480, nRow1=1, nRow2=4, mxGroup=...)
at sc/source/core/data/column4.cxx:2012
#2  0x00007fff9f44448a in ScTable::HandleRefArrayForParallelism(short, int, int, boost::intrusive_ptr<ScFormulaCellGroup> const&)
(this=0x1eebda0, nCol=0, nRow1=1, nRow2=4, mxGroup=...) at sc/source/core/data/table1.cxx:2567
#3  0x00007fff9f06b691 in ScDocument::HandleRefArrayForParallelism(ScAddress const&, int, boost::intrusive_ptr<ScFormulaCellGroup> const&)
(this=0x1ba9a40, rPos=..., nLength=4, mxGroup=...) at sc/source/core/data/document.cxx:1792
#4  0x00007fff9f3018f7 in (anonymous namespace)::ScDependantsCalculator::DoIt() (this=0x7fffffff4eb8) at sc/source/core/data/formulacell.cxx:4585
#5  0x00007fff9f30085a in ScFormulaCell::CheckComputeDependencies(sc::FormulaLogger::GroupScope&, bool, int, int, bool)
(this=0x2142cf0, rScope=..., fromFirstRow=false, nStartOffset=0, nEndOffset=3, bCalcDependencyOnly=false) at sc/source/core/data/formulacell.cxx:4720
#6  0x00007fff9f2ff392 in ScFormulaCell::InterpretFormulaGroupThreading(sc::FormulaLogger::GroupScope&, bool&, bool&, int, int)
(this=0x2142cf0, aScope=..., bDependencyComputed=@0x7fffffff56d7: false, bDependencyCheckFailed=@0x7fffffff56d6: false, nStartOffset=0, nEndOffset=3)
at sc/source/core/data/formulacell.cxx:4829

so the CheckComputeDependencies at the start of
ScFormulaCell::InterpretFormulaGroupThreading is successful for aPos of
{nRow = 1, nCol = 1, nTab = 3 } and the cell is not dirty at that point

*however* in the following loop of
for (SCCOL nCurrCol = nColStart; nCurrCol <= nColEnd; ++nCurrCol)
in InterpretFormulaGroupThreading, CheckComputeDependencies for
column 3 is called and the breakpoint #2 is hit, in this case
mxGroup->mbPartOfCycle is true and the {nRow = 1, nCol = 0, nTab = 3 }
cell is set dirty again.

so later during the threaded calculation the cell is found dirty and the
ScFormulaCell::MaybeInterpret() asserts that
!rDocument.IsThreadedGroupCalcInProgress()

Change-Id: I40385f5e8240680c220249dd2966b196efaf5e0f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/155463
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>

0 files changed, 0 insertions, 0 deletions