RE: fdo 37341 MAXRECURSION reached in ScFormulaCell::Interpret

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