Doug MacEachern wrote:
> seems if a script fails to compile ModPerl::Registry still caches it.
> for example, consider the following script called test.pl:
>
> use Foo ();
> ...
>
> where Foo.pm did not exist in @INC. compile fails. ModPerl::Registry
> tries to call the test.pl::handler() fun
seems if a script fails to compile ModPerl::Registry still caches it.
for example, consider the following script called test.pl:
use Foo ();
...
where Foo.pm did not exist in @INC. compile fails. ModPerl::Registry
tries to call the test.pl::handler() function which was never created.
on subse
Doug MacEachern wrote:
> On Fri, 14 Jun 2002, Stas Bekman wrote:
>
>
>>I know. I was debugging this since this morning. Seems that I've found a
>>bug in perl (something has changed in perlio.c after RC1). See the
>>followup at p5p.
>
>
> ok. keep in mind i am planing _03 in the next day or
forget the CGI.pm patch and update modperl-2.0 cvs. no idea why, but the
MP_THREADED macro used by modperl_global.c (#if MP_THREADED) was false on
win32. so instead of using thread local storage for the global
request_rec it was using a global static variable. your test case now works
witho
i can reproduce the problem on win32. all i can see so far is that the
problem is related to using the global request_rec (Apache->request).
with the patch below to CGI.pm to avoid Apache->request and PerlOptions
+ParseHeaders configured, i have no problems running your test case.
would be int
msg.pgp
Description: PGP message
On Fri, 14 Jun 2002, Stas Bekman wrote:
> I know. I was debugging this since this morning. Seems that I've found a
> bug in perl (something has changed in perlio.c after RC1). See the
> followup at p5p.
ok. keep in mind i am planing _03 in the next day or two (so there is a
release that comp
Greetings.
> i can try on windows later today or over the
> weekend. one suspect is exit(0), which is actually die() in
> disguise. i
> wonder if the longjmp (or whatever it does under windows)
> could be part of
> the problem. can you try commenting out the call to exit?
I did and it m
On Fri, 14 Jun 2002, Alessandro Forghieri wrote:
> The attached couple of files is what you asked: by loading the script and
> repeatedly refreshing from the browser, I can make the malformed http etc.
> etc. stuff appear in error.log; the browser starts displaying raw html or
> "Error" in one or
Greetings.
Running NT4SP6, 5.8RC1 compiled debug.
The following session:
D:\Apache2>perl -d -e 42
Loading DB routines from perl5db.pl version 1.19
Editor support available.
Enter h or `h h' for help, or `perldoc perldebug' for more help.
main::(-e:1): 42
DB<1> ;{use threads;my $var=1;thre
Greetings.
> any chance you could put together a self-contained test case
> to reproduce
> the problem? thanks.
The attached couple of files is what you asked: by loading the script and
repeatedly refreshing from the browser, I can make the malformed http etc.
etc. stuff appear in error.log;
> This usually indicates the first line of your script
> #!C:/Perl/bin/perl.exe
> (with the .exe extension) isn't properly pointing to
> the location of your perl binary ...
Thanks for all of your help. Everything is now working!!
> By the way, questions like these would probably be
> more a
Greetings
>
> any chance you could put together a self-contained test case
> to reproduce
> the problem? thanks.
I'll try but "It ain't easy..."
The app I'm on is quite big, not to mention dependent on several other
components, so it isn't really suited to be cut up in pieces for testing
purp
13 matches
Mail list logo
