Re: [Gretl-devel] bug which is new in 1.7.4

Riccardo (Jack) Lucchetti schrieb: 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