fdo 37341 MAXRECURSION reached in ScFormulaCell::Interpret

[Winfried Donkers]

Hi Eike,


>The recursion itself is handled correctly, the added problem here is
>1) we also have a circular dependency (which standalone combined with
   recursion should be handled gracefully)

A circular dependency error is generated, yes, but IMHO this is caused by more cells to be calculated recursvely than MAXRECUSSION.
There is not an actual circular dependency.

>2) the goal seek is triggered by ScDocument::Solver() creating an
>   ScFormulaCell and start Interpret() on it, in
>   ScInterpreter::ScBackSolver() the goal seek's defined formula cell is
>   set dirty over and over again until the confifuration's limit is
>   reached

Actually, ScBacksolver() doesn't keep calling Interpret() (in my simple testcase, Interpret is called 35 times -of which only one occasion leads to interpreting the formula- by ScBacksolver() ), but Scbacksolver() is called again and again. 
I fear that this is because Interpret does not set an ErrorCode (such as erCircularReference) so that ScbackSolver() doesn't know there is a problem.
The same call is repeated; as Interpret returns the same result regardless of the starting value, ScBacksolver() keeps changing its starting value...

>I'd investigate first why the loop in ScInterpreter::ScBackSolver() isn't terminated, i.e. why changing the start value does not alter the result. If it is correct that it doesn't >change anymore than ScBackSolver() will have to detect that.

ScBackSolver() does detect this, bHorMoveError becomes true.
But the caller of ScbackSolver() (I haven't pinpointed this caller) doesn't notice that.

>If the culprit seems to be within ScFormulaCell::Interpret() then, well, ... I can't say much else would help than stepping through these calls and keeping track of what called >which in what state. The old code had some debugging/tracing facilities that generated a .dot file from within
>ScFormulaCell::Interpret() but unfortunately got completely removed with
>5ff49e8ce958deb8217880b2aaf2bd41a567e8a1 (these are the cases where I don't understand blind removal of #ifdef'ed code) so for testing purposes you might want to >revive the part of sc/source/core/data/cell.cxx of that change into sc/source/core/data/formulacell.cxx

Well, I tend to think that reaching the MAXRERCUSION count should result in some sort of error as the caller of Interpret() needs to know whether the result is valid.
I haven't been able to find 5ff49e8ce958deb8217880b2aaf2bd41a567e8a1 (my clumsiness), so I would need an extra hint to restore (part of) the debugging/tracing facilities.

Winfried