In Sandbox.pm, the following is being executed:
open ( STDERR, '>&STDOUT' ) or die "can't redirect STDERR: $!\n";
Which burps the following errors (using mod_perl) with I hit /bin/view:
can't redirect STDERR: Bad file descriptor
TWiki::UI::__ANON__('can\'t redirect STDERR: Bad file descriptor\x{a}') called at /var/www/localhost/htdocs/twiki/lib/TWiki/Sandbox.pm line 319
{...}
If I just define STDOUT immediately prior, the problem goes away:
open (STDOUT, ">", "foo.out") or die;
open ( STDERR, '>&STDOUT' ) or die "can't redirect STDERR: $!\n";
update: The problem only "went away" temporarily... after browsing a few pages it returned)
update 7/10/05 17:15 EST: I also found:
http://www.twiki.org/cgi-bin/view/Support/RegistryCookerBadFileDescriptor, which describes a similar problem related to mod_perl 1.99_11. For some reason my version of mod_perl is not spitting 1.99_11, but rather 1.9911 (output from /bin/configure below):
mod_perl Used for this script
mod_perl is loaded into Apache
mod_perl version 1.9911
So perhaps there are two issues:
- Changes to Sandbox.pm (reverted entire tree to SVN 4556 and do not have this issue)
- Checking for 1.99_11 may not work as intended, at least with my Gentoo build of mod_perl. Might add and "OR" to the check to look for 1.9911 as an invalid version as well.
Tested the following with SVN 4556 and /bin/configure returns the proper error message.
===================================================================
--- configure (revision 4556)
+++ configure (working copy)
@@ -1387,7 +1387,7 @@
# Check for a broken version of mod_perl 2.0
if ( $usingModPerl and $modPerlVersion >= 1.99
- and $modPerlVersion eq '1.99_11' ) {
+ and ($modPerlVersion eq '1.99_11' || $modPerlVersion eq '1.9911') ) {
# Recommend mod_perl upgrade if using a mod_perl 2.0 version
# with PATH_INFO bug (see Support.RegistryCookerBadFileDescriptor)
$block .= _setting('', WARN(<<HERE
The changes I made were because earlier revs were
broken - STDERR was being thrown away in the safe pipes model. The reality is that we can dispense with STDERR, but the problem is that in the emulated safe pipes mode, STDERR needs to be redirected or it outputs to the console (apache error_rlog)
When the child process that actually executes the command is forked, STDOUT is supposed to be inherited from the parent process. If STDOUT isn't open (and it would appear not to be) this is a major problem for mod_perl.
You are not clear above if you are happy that the problem is understood? There seem to be two possible course of action:
- Fix configure to detect broken mod_perl correctly
- Fix sandbox so it doesn't redirect STDERR
Which is it to be?
CC
- configure should be "fixed" to correctly perform the task that it was designed to do already -- report to the user that 1.99_11 isn't going to work -- and do it correctly no matter how mod_perl reports the version name.
- I don't know the best way to fix Sandbox.pm. You understand the issue better than I. I'll try the latest source again with mod_perl 1.99_17, to see if it is fixed with mod_perl.
Perhaps BOTH issues are related to mod_perl 1.99_11 -- and therefore both problems were caused by my machine. I didn't, however, realize that mod_perl 1.99_11 was not acceptable. Currently it's thoe most recent version that's "unmasked" through Gentoo's package system, which means that any user who installs mod_perl will get 1.99_11. It's unclear which version of mod_perl is currently stable with Apache2. If there is a recommendation that you're aware of, I would also report it to the user in /bin/configure
If there is only one course of action possible ("which is it to be?"), configure should be fixed if it prevents other users from discovering the same issues.
OK, thanks Bill. Redirection of STDERR is not a bug, it's a requirement on the Sandbox, so we should only do that if there is absolutely no other choice. Please let us know what you find out; if everything looks ok, just set the
CurrentState of this report to 'Closed'. I have improved the expression that checks in configure, and the explanatory text. SVN 4606
CC
Since my last comment I have changed the Sandbox back to throw STDERR away. Cairo behaviour was completely unclear on this point, with a mix of both; now at least it is consistent. The problem with returning STDERR is that it gets interleaved with output. It is pretty useless anyway; if there is an error, the exit code is used.
CC