Steve Hay wrote:
Randy Kobes wrote:

On Fri, 3 Oct 2003, Stas Bekman wrote:


If it is happening on the server side, may be it happens
due to a previous request not restoring the overriden STD
stream at the end of its run? We have the error checking,
but it may fail nevertheless?


It sounds like that might be happening, especially
since it's on a predictable subset of tests (eg,
apache/scanhdrs, but apache/constants is OK). I'll
try to put it through the debugger to see if that
sheds any light.


I'm not sure that it's related to the actions of previous requests because it happens with a single test which only makes one request.

I've been trying to debug what goes on when I run this:

perl t/SMOKE modperl\post_utf8

This single test is one of those that fails with the "Failed to dup STDOUT" error. I've put a break point on the line that fails and a pause near the start of the test script itself so that I can attach the debugger to Apache.exe when the test script starts up. The one and only time that the breakpoint is visited is the time that it fails. At this point the call stack is:

=====
modperl_io_perlio_override_stdout(interpreter * 0x011fa0f4, request_rec * 0x03386160) line 137
modperl_response_handler_cgi(request_rec * 0x03386160) line 918 + 13 bytes
ap_run_handler(request_rec * 0x03386160) line 195 + 78 bytes
ap_invoke_handler(request_rec * 0x03386160) line 401 + 9 bytes
ap_process_request(request_rec * 0x03386160) line 288 + 9 bytes
ap_process_http_connection(conn_rec * 0x0084c650) line 293 + 9 bytes
ap_run_process_connection(conn_rec * 0x0084c650) line 85 + 78 bytes
ap_process_connection(conn_rec * 0x0084c650, void * 0x0084c588) line 213
worker_main(long 0) line 731
_threadstartex(void * 0x0028d2c8) line 212 + 13 bytes
KERNEL32! 77e7d33b()
=====


I stepped into the Perl_do_open() call, and into Perl_do_openn(). Around line 106 of Perl (5.8.1)'s doio.c we have:

   /* If currently open - close before we re-open */
   if (IoIFP(io)) {
   ...
   }

It may or may not be relevant to note that the above if-block was skipped over. Does that imply that STDOUT is actually closed at this point after all?

No, 'io' is the handle that STDOUT is going to be dupped to, and as you tested with my last patch it doesn't make any difference if we explicitly close it.


Continuing walking through Perl_do_openn() we visit line 389 (with dodup set to 2):

fp = PerlIO_fdupopen(aTHX_ that_fp, NULL, dodup);

looks good


[which returns via line 536 of perlio.c] and later on line 555:

fd = PerlIO_fileno(fp);

which sets fd to 35 (!),

sounds quite possible


. We then go to line 561:

if (PerlLIO_fstat(fd,&PL_statbuf) < 0) {

and then it all goes wrong because sadly that PerlLIO_fstat() fails and we return FALSE via lines 563, 564, 697, etc. The PerlLIO_fstat() call actually winds up being _fstati64() on line 500 of win32/win32sck.c, and returned -1.

I'd step through PerlIO_fdupopen(aTHX_ that_fp, NULL, dodup);

and see that the dup goes correctly. If stat fails that means that the above has failed. May be it needs a check?

Does any of this help anyone divine what is going wrong?

I also tried running the script with I/O tracing on. Here's what I get in the error_log:

   modperl_io.c:99: start
   modperl_io_apache.c:57: done
   modperl_io_apache.c:32: mode r
   modperl_io_apache.c:71: did nothing
   modperl_io.c:118: end
   modperl_io.c:131: start
   Failed to dup STDOUT: Permission denied.

The first start ... end section is modperl_io_perlio_override_stdin(); then we start modperl_io_perlio_override_stdout() and croak() straight away. Doesn't really tell me much either :-(

What else can I try?

Beside the suggestion above, I'd try to step though through a good do_openn called from modperl_io_perlio_override_stdout and compare with the failing one.




__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to