RE: fdo 37341 MAXRECURSION reached in ScFormulaCell::Interpret

Hi Kohei,

> 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

As you seem to be the expert on formulacell.cxx and the (Back)Solver() code, I hope you can shed 
some light on this problem.

Setting a breakpoint at the start of ScInterpreter::ScBackSolver() indicated that ScBackSolver is 
called again and again from within ScFormulaCell:Interpret().
First, a call originates from line 966, but then the calls originate from line 1129, which is in a 
do-while loop. This do-while loop takes longer and longer in the case of reaching MAXRECURSION. The 
number of iterations in this loop keeps increasing (up to thousands, with only 7 cells in the 
document in use).
I wonder why ScBackSolver is called at all (apart from the first time. which was user-initiated). 
The first call of ScBackSolver() is from ScViewFunc::Solve()/ScDocument::Solver(), but the other 
calls are not. ScBackSolver ends correctly (AFAICS) with error code NOTAVAILABLE, but the loop in 
ScFormulaCell:Interpret() does not.
In the source code there is only one location where ScBackSolver() is called: ScDocument::Solver().

Could it be that InterpretTail() goes down the stack too deep when MAXRECURSION has been reached? 



Winfried