I just found the following. Given there's a scheduled redirect. Then printing out the complete page to STDOUT will immediately send the page to the browser and quit the cgi process without twiki having a chance to clean up using the finish() methods. You will observe that the called method in UI.pm will not return.

That obviously has got a series of consequences, e.g. this is a memory leak. In addition, the cgi session object is not flushed to disk. Not flushing the cgi session will result in session variables getting lost or session variables not being deleted.

Can anybody confirm this?

-- MichaelDaum - 23 Jun 2008

I'm pretty sure you are right. I'm also reasonably sure that the TWiki Standalone work will eliminate this legacy.

-- SvenDowideit - 24 Jun 2008

even nastier are the number of Plugins that take return die or other shortcuts to exit. Too much assumption that its a single exec per request CGI.

-- SvenDowideit - 25 Jun 2008

Honestly they could, if they just finished the session object regularly. For instance, the RedDotPlugin is doing its own redirect stuff ... based on the content of session variables. Just before it redirects the cgi query, it clears the value of the session variable ... but that won't get flushed to disk as the official redirect will happen at a phase of the code where the session does not get finished and thus never flushed to disk. So the only solution for RedDot is to finish() the twiki object itself and exit.

-- MichaelDaum - 26 Jun 2008

Not sure I fully understand the problem here. A CGI::redirect does not of itself quit the calling process; it simply prints a redirect header on STDOUT. The print usually isn't flushed until the process is quit by a subsequent exit. So, if you perform a redirect and then immediately exit without an intervening finish then yes, there is a problem. A quick review of the TWiki core code suggests that all redirects have a finish call before the exit, however; unless you know of a specific counter-example?

Users of TWiki::Func::redirectCgiQuery will be caught by this, if they have not explicitly called finish. I was aware of this problem but didn't move the finish and exit into TWiki::redirect because that would have broken the pre-existing spec of TWiki::Func::redirectCgiQuery.

Note that plugins that die or throw are already in good shape because TWiki::UI handles the finish.

-- CrawfordCurrie - 27 Jun 2008

The way I discovered this is that the session object was not flushed to disk on a redirect, which is a natural consequence of the finish() methods not being called. Poor-man's-debugging (adding print STDERR) showed that as soon as the CGI::redirect was print to STDOUT, the method called in TWiki::UI did not return and thus the finish() call at the end did not get called. Further debugging lent me to the conclusion that all of the process was gone already.

Can anybody reproduce this behavior?

-- MichaelDaum - 30 Jun 2008

I changed UI.pm

63a64,65
>     print STDERR "run starts for method $method\n";
> 
199a202
>     print STDERR "run finished for method $method\n";

in order to see the effect. I surfed some pages. But all messages (even in redirect cases) are paired in the sense

run starts for method CODE(0xb6fba0)
run finished for method CODE(0xb6fba0)
run starts for method CODE(0xb71070)
run finished for method CODE(0xb71070)

Can you describe in what redirect situation this happens? Are there special redirects where this happens? And what's a "scheduled" redirect?

-- ChristianLudwig - 30 Jun 2008

Would a sleep work? Waiting 0.2 sec on a redirect is not noticeable by users

-- TWiki:Main.PeterThoeny - 07 Jul 2008

TWiki:Codev.GeorgetownReleaseMeeting2008x07x21 decided to downgrade to normal with the comment that the conclusion in the report is probably not correct.

-- KennethLavrsen - 22 Jul 2008

No one answers on this one so I No Action it

• KennethLavrsen - 24 Dec 2008