[Gretl-devel] bug which is new in 1.7.4

[Sven Schreiber]

Riccardo (Jack) Lucchetti schrieb:
> On Wed, 2 Apr 2008, Sven Schreiber wrote:
> 
>> Hi,
>>
>> I have a relatively complicated bootstrap script which works with 
>> 1.7.3 (I just re-confirmed this) but stops working with 1.7.4. Gretl 
>> 1.7.4 just hangs (becomes unresponsive forever, like being in an 
>> infinite loop) and has to be killed by the OS. All this is on Windows 
>> XP, I cannot test on Linux before the weekend (if that's needed).
>>
>> I haven't had time to pin down the bug yet, but I suspect it may have 
>> to do with the 'resample' changes that were introduced in 1.7.4. I'm 
>> using the resample command with matrices (well, the pre-1.7.4 usage).
>>
>> I haven't tested a recent snapshot yet, should I? I may be able to 
>> test some more this afternoon (Central European time).
> 
> Debugging something like this is most likely near-impossible unless you 
> provide a testcase. The smaller, the better.
> 


Yeah I know, but it's not so easy. I haven't been able to find a 
stripped-down testcase so far; however, I have some more information on 
my case -- sorry for the longish explanation, but that's all I can come 
up with. I could prepare a non-stripped-down testcase tomorrow if that's 
useful.

The framework I'm using is a main file ("frontend") in which there is a 
call to a function that resides in a second script file ("backend", 
which in turn calls other functions in the same file, but that seems 
irrelevant here).

The crucial part of the frontend is:

<frontend_snippet>
include permaconftestbackend.inp
set stopwatch
list results = pconfbackend(endo,rexo,uexo,cirank,lagorder,determcase, \
   varselector,confcoverage,dodelta,doboot,numofW)
</frontend_snippet>

and the backend ends with:

<backend_snippet>
return list results
end function
</backend_snippet>

The backend includes a 'resample' command among many other things, but 
I found out by testing that the backend actually seems to run just fine 
until the very end of the function; i.e. when I augment the backend with 
debugging code like so:

<backend_snippet>
return list results
funcerr "so until the end?"
end function
</backend_snippet>

the code executes and I get the expected error message that I defined in 
the funcerr statement.

First conclusion: The 'resample' command in the backend doesn't seem 
responsible for the hanging.

But when I remove the funcerr statement from the backend, and instead 
add something similar to the frontend right after the function call, 
like so:

<frontend_snippet>
include permaconftestbackend.inp
set stopwatch
list results = pconfbackend(endo,rexo,uexo,cirank,lagorder,determcase, \
   varselector,confcoverage,dodelta,doboot,numofW)
funcerr "something totally different?"
</frontend_snippet>

then gretl hangs (1.7.4, not 1.7.3) and the 'funcerr' statement is never 
reached.

Second tentative conclusion: The problem seems to be either the passing 
of result lists from function to caller, or maybe something more 
general/subtle about the function calling mechanism. Or is it the genr 
mechanism?

============================================

BTW, during debugging (using a bunch of 'funcerr' statements), I 
stumbled over other quirks:

1) At some point I got an error saying "IF depth exceeded" or something 
like that. Now I don't nest that many IF blocks, so I guess this 
happened because I repeatedly interrupted functions in the middle of IF 
blocks by using 'funcerr'. But that suggests that some "stacks" (or 
whatever they're called) are not properly cleaned up when a function 
exits with an error -- gretl is accumulating all the IF stuff of the 
past, if you know what I mean.

2) For weeks now I have often got errors about allegedly "missing values 
found" which were all bogus. These errors are not robust in the sense 
that just re-running the affected scripts will sometimes solve the 
problem. Or sometimes some trivial things like changing a line and 
changing it back are necessary to solve it. But that's why it's also 
very difficult to provide testcases (and which is also the reason why I 
haven't reported it before). Maybe another temporary-memory-stack 
problem in the background?

Thanks for reading until the end!

/sven