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
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?
- 23 Jun 2008
I'm pretty sure you are right. I'm also reasonably sure that the TWiki Standalone work will eliminate this legacy.
- 24 Jun 2008
even nastier are the number of Plugins that take
or other shortcuts to exit. Too much assumption that its a single exec per request CGI.
- 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
- 26 Jun 2008
Not sure I fully understand the problem here. A
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
. So, if you perform a redirect and then immediately
without an intervening
then yes, there is a problem. A quick review of the TWiki core code suggests that all redirects have a
call before the exit, however; unless you know of a specific counter-example?
will be caught by this, if they have not explicitly called
. I was aware of this problem but didn't move the
because that would have broken the pre-existing spec of
Note that plugins that
are already in good shape because
- 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
methods not being called. Poor-man's-debugging (adding print STDERR) showed that as soon as the
was print to STDOUT, the method called in
did not return and thus the
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?
- 30 Jun 2008
I changed UI.pm
> print STDERR "run starts for method $method\n";
> 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?
- 30 Jun 2008
Would a sleep work? Waiting 0.2 sec on a redirect is not noticeable by users
- 07 Jul 2008
decided to downgrade to normal with the comment that the conclusion in the report is probably not correct.
- 22 Jul 2008