Stas Bekman wrote:
... You should be able then to reproduce
this outside Apache-Test, just doing:
httpd > /dev/null &
and then trying to run requests on it, should reproduce the problem.
It's probably should be reproducable by a simple attempt to do:
print STDOUT "It works";
from the startup.pl
On Wed, 8 Oct 2003, Stas Bekman wrote:
> Now, that makes much more sense, Randy. Looks like we are
> making a progress on this. Indeed as you said doing
> 't/TEST -run testname' doesn't affect the server side. But
> the way you start the server does.
>
> I suppose this has something to do with the
Randy Kobes wrote:
[...]
I've attached a patch (for Steve's benefit, as it's Win32
specific) which, first of all, uses Win32::Process (to
rule out problems coming from IPC::Run3), and which defines
two functions:
run_command - uses system() to run a command, and
returns a flag ind
On Wed, 8 Oct 2003, Stas Bekman wrote:
> Randy Kobes wrote:
[ ... ]
> Thanks, Randy. And if you run:
>
> perl t/TEST -start
> perl t/TEST -run testname
> perl t/TEST -stop
This works ...
> if this still works, what if you run TestSmoke's test_run alone by ripping it
> off and just hardcoding thi
Geoffrey Young wrote:
test suites are good for excercising functionality and some error
conditions, but not always for reproducing real-world issues like
that, unfortunately.
Frankly I don't think this applies to the undef-warn-on-exit problem,
it's reproducable in a trivial cgi script. It mu
Randy Kobes wrote:
On Wed, 8 Oct 2003, Stas Bekman wrote:
Steve Hay wrote:
[ .. ]
Do you have the same issue if you run them as:
perl t/TEST testname
instead of using 'nmake'? If that's the case, it's not an issue with SMOKE.
Running the tests that fail under t/SMOKE as
perl t/TEST test
On Wed, 8 Oct 2003, Steve Hay wrote:
> I think I've cracked it myself looking at those two files.
> The original .dsp file has two lines like this:
> ADD CPP ... /I "\Perl\lib\CORE" ...
> which get fixed up by Makefile.PL to this:
> ADD CPP ... /I "\Perl\lib\CORE" /I "C:\apache\include" /
test suites are good for excercising functionality and some error
conditions, but not always for reproducing real-world issues like
that, unfortunately.
Frankly I don't think this applies to the undef-warn-on-exit problem,
it's reproducable in a trivial cgi script. It must be something else i
On Wed, 8 Oct 2003, Stas Bekman wrote:
> Steve Hay wrote:
[ .. ]
> Do you have the same issue if you run them as:
>
>perl t/TEST testname
>
> instead of using 'nmake'? If that's the case, it's not an issue with SMOKE.
Running the tests that fail under t/SMOKE as
perl t/TEST testname
report
Geoffrey Young wrote:
[...]
right, sorry. So it should be easy to revert in the previous code,
once we figure out what gets onto the stack when exit() is called (I'd
guess that it'll be undef).
according to perlapi, yes: for Perl_croak count is 1 and undef is on the
stack with G_EVAL.
so why n
Stas Bekman wrote:
Geoffrey Young wrote:
is it possible that that later on we will have callbacks that return
a string, which is a valid thing? Aren't we guessing here again?
well, I suppose DIR_MAGIC_TYPE and DECLINE_CMD are both strings, but
they managed to (somehow) work before.
I supp
Geoffrey Young wrote:
is it possible that that later on we will have callbacks that return a
string, which is a valid thing? Aren't we guessing here again?
well, I suppose DIR_MAGIC_TYPE and DECLINE_CMD are both strings, but
they managed to (somehow) work before.
I suppose, that's because we n
With apache-1.3, mod_perl users were able to do:
some code
in httpd-2.0, the configuration parser doesn't like container directives
with no arguments (Syntax error on line nn of httpd.conf:
directive missing closing '>'). So, for now, users have to resort to
using this syntax (note the extra
Geoffrey Young wrote:
(apr_port_t)modperl_callback_per_srv(MP_DEFAULT_PORT_HANDLER, rr,
MP_HOOK_RUN_FIRST);
discards 'const'. which is not trivial to fix, so I stopped there,
removed your change and finished building the project.
So any suggestions to how to fix that?
not the const requ
is it possible that that later on we will have callbacks that return a
string, which is a valid thing? Aren't we guessing here again?
well, I suppose DIR_MAGIC_TYPE and DECLINE_CMD are both strings, but they
managed to (somehow) work before.
other than that, if we declare that current_callback
Geoffrey Young wrote:
the issue here isn't related to the new hook, but rather my use of
setting the return status based on $r->args - I think $port was
getting assigned the PV value and mod_perl isn't getting the
associated IV. int() was just my workaround.
confirmed via Devel::Peek.
but y
(apr_port_t)modperl_callback_per_srv(MP_DEFAULT_PORT_HANDLER, rr,
MP_HOOK_RUN_FIRST);
discards 'const'. which is not trivial to fix, so I stopped there,
removed your change and finished building the project.
So any suggestions to how to fix that?
not the const request_rec *r part, no. I
the issue here isn't related to the new hook, but rather my use of
setting the return status based on $r->args - I think $port was getting
assigned the PV value and mod_perl isn't getting the associated IV.
int() was just my workaround.
confirmed via Devel::Peek.
but yes, it's somewhat of a r
Steve Hay wrote:
Stas Bekman wrote:
Steve Hay wrote:
[...]
This makes sense after reading
http://perl.apache.org/docs/2.0/user/config/config.html#C_modperl_
http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
and sure enough the various tests that fail, e.g.
apache\
Steve Hay wrote:
Stas Bekman wrote:
Steve Hay wrote:
[...]
Line 2457 of perlio.c sets fd to 1 (which is STDOUT, right?) flags is
still 2, so (flags & PERLIO_DUP_FD) is true and we call PerlLIO_dup()
on line 2459. That calls win32_dup(), which calls dup(), which I
can't step into ;-). Each
Stas Bekman wrote:
Steve Hay wrote:
[...]
Line 2457 of perlio.c sets fd to 1 (which is STDOUT, right?) flags is
still 2, so (flags & PERLIO_DUP_FD) is true and we call PerlLIO_dup()
on line 2459. That calls win32_dup(), which calls dup(), which I
can't step into ;-). Each of dup(), win32_dup
Stas Bekman wrote:
Steve Hay wrote:
[...]
This makes sense after reading
http://perl.apache.org/docs/2.0/user/config/config.html#C_modperl_
http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
and sure enough the various tests that fail, e.g.
apache\scanhdrs
api\r
Stas Bekman wrote:
Man, you should at least give us a chance to test patches if you post
them for review and not rushing to commit them. mp2 now can't be even
built. Your patch has several problems. First of all the prototype is
wrong, it should be:
apr_port_t modperl_default_port_handler(con
Steve Hay wrote:
[...]
Line 2457 of perlio.c sets fd to 1 (which is STDOUT, right?) flags is
still 2, so (flags & PERLIO_DUP_FD) is true and we call PerlLIO_dup() on
line 2459. That calls win32_dup(), which calls dup(), which I can't
step into ;-). Each of dup(), win32_dup() and PerlLIO_dup()
Steve Hay wrote:
[...]
This makes sense after reading
http://perl.apache.org/docs/2.0/user/config/config.html#C_modperl_
http://perl.apache.org/docs/2.0/user/config/config.html#C_perl_script_
and sure enough the various tests that fail, e.g.
apache\scanhdrs
api\rflush
modperl\post_
Besides, while looking why this thing is broken, I saw that this is an
HTTP hook and has little to do with protocols, since its defined in
include/http_protocol.h.
so? apache isn't perfectly separated, and a few of the functions are
clearly misnamed or misplaced - see ap_http_method which ret
Stas Bekman wrote:
Stas Bekman wrote:
Man, you should at least give us a chance to test patches if you post
them for review and not rushing to commit them. mp2 now can't be even
built.
Mea Culpa,
that's ok, I'm used to it by now...
it can't be built only with:
MP_CCOPTS='-Werror'
which
Steve Hay wrote:
So presumably it's that failure above, marked (***), which is where
it's all gone wrong. Here's a stack trace showing the path to
my_stat() which calls _fstati64():
=
my_fstat(int 35, _stati64 * 0x02f3fb98) line 532
win32_fstat(int 35, _stati64 * 0x02f3fb98) line 2706 + 13
On Mon, 06 Oct 2003 15:37:12 -0400, Geoffrey Young wrote
> > Should we try to squeeze it into 1.29? If so do we need another release
> > candidate? Since we need 1.29 out asap, because of the bug in 5.8.1, I
> > suggest that we release 1.29 as it is now. Then hopefully we will
> > release 1.30 s
Stas Bekman wrote:
Steve Hay wrote:
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.
[...]
Continuing walking through Perl_do_openn() we visit line 389 (with
dodup set
Randy Kobes wrote:
On Mon, 6 Oct 2003, Steve Hay wrote:
Hi,
During the course of testing mp1.29-rc1 I ran into a strange problem,
probably Windows-specific, which I've seen before but never got to the
bottom of.
I have Apache 1.3.28 installed in C:\apache and Perl 5.8.1 in C:\perl5.
The latte
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 li
32 matches
Mail list logo
