• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

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:

  1. Changes to Sandbox.pm (reverted entire tree to SVN 4556 and do not have this issue)
  2. 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:

  1. Fix configure to detect broken mod_perl correctly
  2. Fix sandbox so it doesn't redirect STDERR
Which is it to be?

CC


  1. 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.
  2. 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

ItemTemplate
Summary Sandbox.pm, STDOUT is not a valid file handle, SVN 4571
ReportedBy BillSkellenger
Priority Normal
CurrentState Closed
WaitingFor

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r7 - 2005-07-15 - TWikiGuest
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback