fdo 37341 MAXRECURSION reached in ScFormulaCell::Interpret

[Winfried Donkers]

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