Re: mod_perl 1.99_10 on AIX 5
Stas Bekman wrote: > > mod_perl 1.99_10 on AIX 5.2 with the IBM vac compiler, using > > perl 5.8.1 without ithreads, is mostly OK. > > > > There's only one test failure : > > > > modperl/subenv.FAILED tests 14-16 > > Failed 3/16 tests, 81.25% okay > > > > Failed Test Stat Wstat Total Fail Failed List of Failed > > --- > > modperl/subenv.t 163 18.75% 14-16 > > 10 tests skipped. > > Can you please run: > > t/TEST -v modperl/subenv > > and also post if anything interesting logged into t/logs/error_log Here's the full test output : $ t/TEST -v modperl/subenv *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -v 'modperl/subenv' consider removing an old /home/garcia/mod_perl-1.99_10/t/core file before running tests /home/garcia/apache2prefork/bin/httpd -d /home/garcia/mod_perl-1.99_10/t -f /home/garcia/mod_perl-1.99_10/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.47 (prefork MPM) waiting for server to start: .[Mon Oct 20 16:32:01 2003] [info] 23 Apache:: modules loaded [Mon Oct 20 16:32:01 2003] [info] 5 APR:: modules loaded [Mon Oct 20 16:32:01 2003] [info] base server + 10 vhosts ready to run tests ... waiting for server to start: ok (waited 3 secs) server localhost:8529 started server localhost:8530 listening (TestProtocol::echo) server localhost:8531 listening (TestProtocol::echo_filter) server localhost:8532 listening (TestPreConnection::note) server localhost:8533 listening (TestHooks::stacked_handlers2) server localhost:8534 listening (TestFilter::in_str_msg) server localhost:8535 listening (TestFilter::both_str_con_add) server localhost:8536 listening (TestFilter::in_bbs_msg) server localhost:8537 listening (TestDirective::perlmodule) server localhost:8538 listening (TestDirective::perlrequire) server localhost:8539 listening (TestPerl::ithreads) server localhost:8540 listening (TestDirective::perlloadmodule3) server localhost:8541 listening (TestDirective::perlloadmodule4) server localhost:8542 listening (TestDirective::perlloadmodule5) server localhost:8543 listening (TestDirective::perlloadmodule6) modperl/subenv1..16 # Running under perl version 5.008001 for aix # Current time local: Mon Oct 20 16:32:02 2003 # Current time GMT: Mon Oct 20 14:32:02 2003 # Using Test.pm version 1.24 ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 ok 13 FAILED tests 14-16 Failed 3/16 tests, 81.25% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- modperl/subenv.t 163 18.75% 14-16 *** server localhost:8529 shutdown !!! error running tests (please examine t/logs/error_log) !!! oh jeez, server dumped core !!! for stacktrace, run: gdb /home/garcia/apache2prefork/bin/httpd -core /home/garcia/mod_perl-1.99_10/t/core Here's the backtrace : (dbx) where sig_coredump(sig = 11), line 367 in "prefork.c" Perl_sv_2mortal() at 0xd40bac0c XS_Apache__RequestRec_subprocess_env() at 0xd41fd9fc Perl_pp_entersub() at 0xd4139a48 Perl_runops_standard() at 0xd41356fc S_call_body() at 0xd40c37bc Perl_call_sv() at 0xd40c7614 modperl_callback() at 0xd40a01b0 modperl_callback_run_handlers() at 0xd409fe80 modperl_callback_per_dir() at 0xd409fbcc modperl_response_handler_run() at 0xd409e594 modperl_response_handler() at 0xd409f034 ap_run_handler(0x208065b8), line 194 in "config.c" ap_invoke_handler(0x208065b8), line 401 in "config.c" ap_process_request(0x208065b8), line 288 in "http_request.c" ap_process_http_connection(0x20802670), line 293 in "http_core.c" ap_run_process_connection(0x20802670), line 85 in "connection.c" ap_process_connection(0x20802670, 0x20802598), line 211 in "connection.c" child_main(child_num_arg = 1), line 694 in "prefork.c" unnamed block $b272, line 788 in "prefork.c" make_child(s = 0x20028b80, slot = 1), line 788 in "prefork.c" perform_idle_server_maintenance(p = 0x20026470), line 923 in "prefork.c" unnamed block $b276, line 1118 in "prefork.c" ap_mpm_run(_pconf = 0x20026470, plog = 0x2005e630, s = 0x20028b80), line 1118 in "prefork.c" main(argc = 6, argv = 0x2ff22ac4), line 660 in "main.c" I'm using httpd 2.0.47. I suspect some portability nastiness with memory handing of environment variables, but that's just an impression. I may have time to dig further in some future. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing and smoking leave a PID file behind
Stas Bekman wrote:
Steve Hay wrote:
Perhaps just slip in "$old_pid = 0;" at the end of the "if (WIN32) {
... }" section to fix this?
Sure, the adjusted patch below does that.
Cool.
However, there is still a bigger problem with this new patch. You've
removed the little hack that I'd left in kill_proc() to remove the
PID file. As you say above this is because you don't want TestSmoke
messing with the PID file at all; instead you want to leave it up to
TestServer. Unfortunately it seems that TestServer::stop(), which
has the code to remove the PID file, doesn't necessarily get run, so
the PID file can still get left behind.
I think, that's pretty simple. Are you sure that SIGINIT handler is
run when you hit Ctrl-C? It doesn't for me quite often, which would be
one explanation why it doesn't get deleted.
The TestSmoke SIGINT handler definitely always gets run. In fact,
depending on exactly when I press Ctrl+C I sometimes get the SIGINT
handler installed by TestRun run as well as that installed by TestSmoke!
But since we now don't try to kill the process based on the the pid in
that httpd.pid file, we don't really have a problem when httpd.pid
doesn't get cleaned. Or am I wrong?
TestServer::stop() *does* still use the PID file to kill Apache when
we're running a smoke because the win32obj that it would otherwise
prefer to use is not available. So we're relying on the fact that
stop() shouldn't be called unless we expect *our* PID file to be in
place (hence we removed the stop() call from the beginning of start(),
for example).
So we shouldn't have a problem with a PID file left behind, but it still
makes me a little nervous and I'd rather it got cleaned up if possible.
I'm really confused what's going on here. As a test I set "perl
t/SMOKE modperl\post_utf8" running and then pressed Ctrl+C to stop
it. That's not an unreasonable thing to do, and I would expect it to
clean up the PID file, but it didn't. Well, not always, anyway!
It seems that TestRun::try_exit_opts() is run first and only calls
TestServer::stop() if the ping() worked. It seems that sometimes it
doesn't, i.e. the server is already stopped. I don't know where it
gets stopped in that case.
I've worked it out now. Don't know why I didn't think of this before.
The reason that the Apache.exe has already gone away is, of course, that
it received the Ctrl+C itself and has stopped of its own accord!
For example, if I Ctrl+C this:
use IPC::Run3;
$SIG{INT} = sub { print "Parent INT\n"; exit };
run3 $^X . ' -e "$SIG{INT} = sub { print \"Child INT\n\"; exit }; 1
while (1)"';
then the output is:
Child INT
Parent INT
i.e. the SIGINT is passed onto the spawned child process which also
therefore exits (rather than being orphaned).
So the problem is presumably that Apache2 doesn't clean up its own PID
file when when it receives a SIGINT. I thought that it did, actually,
but a couple of tests revealed some interesting (mis?)behaviour:
- if I run "C:\apache2\bin\apache.exe" in a shell then two Apache.exe
processes are started (parent + 1 child), and when I press Ctrl+C they
both stop and the PID file is deleted;
- if I run "C:\apache2\bin\apache.exe -X" then, as expected, only one
Apache.exe process is started; pressing Ctrl+C still stops it, but the
PID file is now left behind!
I don't know why single-process mode behaves differently w.r.t. Ctrl+C,
but this is clearly the problem since TestServer::start() does indeed
run Apache in single-process mode on Win32.
Ideally this should be fixed in Apache itself, I think (unless there's a
good reason for the different behaviour, which I doubt), but in the
meantime we could also commit the attached patch to TestRun to
workaround Apache's odd behaviour.
This only leaves the problem of it occasionally picking up the "wrong"
PID file:-
Anyway, I thought I'd add some code in try_exit_opts() to remove the
PID file, but it still didn't always work. I added more code to
print out the PID file that it was deleting and found that sometimes
it is the "wrong" one. Here's what I've added in try_exit_opts(),
just before the "exit_perl $ok" at the end of that function:
my $t_logs = $self->{test_config}->{vars}->{t_logs};
my $pid_file = catfile $t_logs, "httpd.pid";
open my $fh, ">C:\\Temp\\debug.txt";
print $fh "Removing PID file '$pid_file' ...\n";
close $fh;
unlink $pid_file if -e $pid_file;
It seems that whether or not this works depends on exactly when I
happen to press Ctrl+C. One time it said
Removing PID file 'C:\Temp\modperl-2.0\t\logs\httpd.pid' ...
and sure enough the PID file was gone, but another time it said
Removing PID file
'C:\Temp\modperl-2.0\docs\devel\core_explained\CVS\t\logs\httpd.pid' ...
and, of course, the main PID file
'C:\Temp\modperl-2.0\t\logs\httpd.pid' was left behind.
Now I haven't got a clue what's going on. Any ideas?
File::Find looks
RE : [PATCH] add PERL5LIB to @INC in the correct order
> Ayhan Ulusoy wrote: > > If I may add my grain of salt as an -interested- user for this one... > > > > Here's how I would expect PERL5LIB to work : > > Sorry for cutting you short, Ayhan, but we can't and shouldn't change the > way > PERL5LIB works under mp. [Ayhan] I am afraid you _have_ cut it short, Stas. Perhaps even before reading it :) Admittedly, I have generated quite a bit of traffic this week-end, and you seem like a busy man. So, I'll let it slip this time :-) But please do me a favour and read it. -- it's attached. > We agreed that it was a mistake under mp1. We > simply > comply with perl and do nothing special about it. If you have further > thoughts > on PERL5LIB, please make yourself heard on the p5p list. [Ayhan] But I am perfectly happy with the way Perl handles PERL5LIB, and agree that mod_perl should keep the Perl way. But it doesn't ... so that's why I'm bringing it up in the mod-perl dev list, not p5p. If you are referring to the behaviour with regards to '-T', I don't have any problems with the way Perl handles it. Yes, mp1 behaviour for PERL5LIB under '-T' was a mistake. The mp2 way is GOOD with regards to that. I had not said anything to the contrary. What is described in my original post is basically what Geoff was talking about. In a nutshell, it's about being a able to set PERL5LIB on a per Server/Directory/Location or per request basis. This works perfectly well today with perl scripts running under MOD_CGI. Under MOD_CGI, I can do a "SetEnv PERL5LIB =xyz" on a per Directory/Location or even Request basis (via mod_rewrite). Since the perl interpreter will be invoked each and every time for a CGI script, it will take that PERL5LIB into account. If I am not mistaken, "ModPerl::PerlRun" and to some extent "ModPerl::Registry" are designed to emulate MOD_CGI behaviour. The way things are today, they DON'T --as far as PERL5LIB is concerned. On the other hand, performance may certainly be an issue here. That's why I have suggested that this behaviour be optional. Geoff, don't you have any comments here ? Please help :) > > If you want to change @INC in mp2, you should use the lib pragma in the > startup file or the PerlSwitches -I idiom. Do always use -T and don't use > PERL5LIB (because it's ignored with -T). [Ayhan] Again, I have no problems whatsoever with the way Perl behaves with respect to PERL5LIB under '-T'. It _should_ behave that way. Please read the attached post. It attempts to answer your question as to why Perl does it that way, and why that is good. Agreed also that it is good to use '-T' as a rule of thumb, especially in production environments. On the other hand, Perl gives me the choice whether or not I want to use '-T' in a given situation. It's good to have that choice. Cheers, Ayhan --- Begin Message --- Title: RE : [PATCH] add PERL5LIB to @INC in the correct order Taint mode is another business. It is the "paranoid" mode, where anything that comes from the outside world, including the environment, is considered untrusted by default, until you explicitly untaint it. If I, *) know (or guess) that your code calls SomeModule->doSomething(), *) have a way to set up PERL5LIB *) gained write access to some directory (say /tmp) I could cause your script to do anything I want when it calls SomeModule->doSomething(). One may say, those "if"s are unlikely to occur, but this is the "paranoid" mode, where "unlikely" is not in the dictionary. The strict behaviour of taint-mode forces the script to do a "use lib" explicitly if it wants to "use" modules from some non-standard directory. Cheers, Ayhan -Message d'origine- De : Geoffrey Young [mailto:[EMAIL PROTECTED]] Envoyé : vendredi 17 octobre 2003 01:56 À : Stas Bekman Cc : [EMAIL PROTECTED] Objet : Re: [PATCH] add PERL5LIB to @INC in the correct order > OK, I'm convinced on this one. We should add a new entry to > porting/compat.pod then, including you summary above. Should I do that, > or will you handle that. I'll put it on my ToDo. > > I still want to know why PERL5LIB is ignored by perl, I will ask p5p as > perlsec.pod doesn't say anything about it. yeah, me too. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --- End Message --- --- Begin Message --- Title: RE : [PATCH] add PERL5LIB to @INC in the correct order If I may add my grain of salt as an -interested- user for this one... Here's how I would expect PERL5LIB to work : 1) Ability to set it in httpd.conf on a per server, vhost, directory or location basis. 2) Ability to set it on a per request basis as well (via SetEnvIf or
RE : RE : porting Sandwich to mp2
Hi Geoff, Please be ensured : this thing doesn't have a real name yet, and before it does, the mod_perl list will be pinged. It just needed one for the development... I am counting on you though to give feed-back on the mod_perl list when it comes to choosing a real name :-) Cheers, Ayhan > -Original Message- > From: Geoffrey Young [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 19, 2003 3:18 PM > To: Ayhan Ulusoy > Cc: 'Stas Bekman'; [EMAIL PROTECTED] > Subject: Re: RE : porting Sandwich to mp2 > > > > > > This module (let's call it Apache::Filter::CheeseBurger) > > please don't release a module with that name on CPAN - Apache::Sandwich is > bad enough - it remains for historical reasons, created far before we (as > a > community) started taking our namespace seriously :) > > the proper way to release something to CPAN in the Apache:: namespace is > to > ping the main mod_perl list with an RFC and wait for feedback. although > this isn't always followed, it's generally a wise thing to do and would be > greatly appreciated > > --Geoff > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Ayhan Ulusoy wrote:
Ayhan Ulusoy wrote:
If I may add my grain of salt as an -interested- user for this
one...
Here's how I would expect PERL5LIB to work :
Sorry for cutting you short, Ayhan, but we can't and shouldn't change
the
way
PERL5LIB works under mp.
[Ayhan]
I am afraid you _have_ cut it short, Stas. Perhaps even before reading
it :)
I'm sure he did read it. he even updated the docs accordingly.
Geoff, don't you have any comments here ? Please help :)
yes. I agree with stas - PERL5LIB should be left to perl, and left without
interference from mod_perl.
keep in mind that PERL5LIB _does_ indeed work: provided your interpreter is
not running under -T and $ENV{PERL5LIB} is populated when the interpreter is
spawned, it will be recognized.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: porting Sandwich to mp2
> "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: SB> modperl list... Also it's probably a good idea to ask the owner of SB> Apache::Sandwich whether they aren't working on a mp2 port already. I am not. Feel free to adopt it. Personally, I don't use it anymore in preference to a real templating system such as Template Toolkit. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
modperl_callback() guessing revisited
hi all
in continuing the discussion from last week (or was it the week before)
where we decided to fix the PL_sv_undef thing first then re-examine
modperl_callback's second-guessing the return value of the Perl callback...
attached is a patch that fixes things to how I think they should work
--Geoff
Index: src/modules/perl/modperl_callback.c
===
RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.63
diff -u -r1.63 modperl_callback.c
--- src/modules/perl/modperl_callback.c 11 Oct 2003 08:01:00 - 1.63
+++ src/modules/perl/modperl_callback.c 20 Oct 2003 16:11:00 -
@@ -100,12 +100,6 @@
"handler %s didn't return a valid return value!",
handler->name);
}
-
-/* assume OK for non-HTTP status codes and for 200 (HTTP_OK) */
-if (((status > 0) && (status < 100)) ||
-(status == 200) || (status > 600)) {
-status = OK;
-}
}
PUTBACK;
Index: t/modperl/status.t
===
RCS file: /home/cvspublic/modperl-2.0/t/modperl/status.t,v
retrieving revision 1.2
diff -u -r1.2 status.t
--- t/modperl/status.t 15 Oct 2003 12:38:36 - 1.2
+++ t/modperl/status.t 20 Oct 2003 16:11:01 -
@@ -10,7 +10,7 @@
NOT_FOUND SERVER_ERROR FORBIDDEN
HTTP_OK);
-plan tests => 14;
+plan tests => 15;
my $base = "/TestModperl__status";
@@ -62,21 +62,22 @@
$uri);
}
-# the return code guessing game
+# apache translates non-HTTP codes into 500
+# see ap_index_of_response
{
-my $uri = join '?', $base, Apache::HTTP_OK;
+my $uri = join '?', $base, 601;
my $code = GET_RC $uri;
-ok t_cmp(Apache::HTTP_OK,
+ok t_cmp(Apache::SERVER_ERROR,
$code,
$uri);
}
{
-my $uri = join '?', $base, 601;
+my $uri = join '?', $base, 313;
my $code = GET_RC $uri;
-ok t_cmp(Apache::HTTP_OK,
+ok t_cmp(Apache::SERVER_ERROR,
$code,
$uri);
}
@@ -85,19 +86,25 @@
my $uri = join '?', $base, 1;
my $code = GET_RC $uri;
-ok t_cmp(Apache::HTTP_OK,
+ok t_cmp(Apache::SERVER_ERROR,
$code,
$uri);
}
-# apache translates non-HTTP codes into 500
-# see ap_index_of_response
+# HTTP_OK is treated as an error, since it's not
+# OK, DECLINED, or DONE. while apache's lookups
+# succeed so the 200 is propagated to the client,
+# there's an error beneath that 200 code.
{
-my $uri = join '?', $base, 313;
-my $code = GET_RC $uri;
+my $uri = join '?', $base, Apache::HTTP_OK;
+my $response = GET $uri;
-ok t_cmp(Apache::SERVER_ERROR,
- $code,
+ok t_cmp(Apache::HTTP_OK,
+ $response->code,
+ $uri);
+
+ok t_cmp(qr/server encountered an internal error/,
+ $response->content,
$uri);
}
Index: t/response/TestModperl/current_callback.pm
===
RCS file: /home/cvspublic/modperl-2.0/t/response/TestModperl/current_callback.pm,v
retrieving revision 1.3
diff -u -r1.3 current_callback.pm
--- t/response/TestModperl/current_callback.pm 31 Mar 2003 01:50:52 - 1.3
+++ t/response/TestModperl/current_callback.pm 20 Oct 2003 16:11:01 -
@@ -36,6 +36,7 @@
die "expecting $expected callback, instead got $callback"
unless $callback eq $expected;
#warn "in callback: $callback\n";
+return Apache::OK;
}
1;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: RE : [PATCH] add PERL5LIB to @INC in the correct order
Ayhan Ulusoy wrote: I am afraid you _have_ cut it short, Stas. Perhaps even before reading it :) Admittedly, I have generated quite a bit of traffic this week-end, and you seem like a busy man. So, I'll let it slip this time :-) Guilty as charged, but I said that in first place ;) Since I've to read email traffic on about 15 or so mailing lists, all in one way or another affecting mod_perl, I have to adopt some sort of filtering in my head, without which I won't be able to do any work at all, but spend all the time just reading emails all day long. So normally I do that by looking at the subject and sometimes the first para of the post. [that's another reason why I asked you to post different issues in different posts ;)]. Therefore please bear with me and feel free to nudge me if my in-head-filter has ignored your email, just like you did now ;) But please do me a favour and read it. -- it's attached. I did now, and you bring points that Geoff has already mentioned: PERL5LIB setting per-dir doesn't work in mp1, so it won't work under mp2. If you are referring to the behaviour with regards to '-T', I don't have any problems with the way Perl handles it. Yes, mp1 behaviour for PERL5LIB under '-T' was a mistake. The mp2 way is GOOD with regards to that. I had not said anything to the contrary. What is described in my original post is basically what Geoff was talking about. In a nutshell, it's about being a able to set PERL5LIB on a per Server/Directory/Location or per request basis. The solution is simple - don't use PERL5LIB, use PerlSwitches as I've documented here: http://perl.apache.org/docs/2.0/user/config/config.html#Adjusting_C__INC_ http://perl.apache.org/docs/2.0/user/config/config.html#Modifying_C__INC__on_a_Per_VirtualHost So the Vhost solution perfectly answers your problem with setting up a different @INC, for different setups running on the same server. Another crafty solution would be to use PerlInitHandler to push some libs onto @INC and PerlCleanupHandler to pop them away. Apache::PerlVINC in mp1 does exactly that. Feel free to port it to mp2 / talk to the author first? http://search.cpan.org/~davem/Apache-PerlVINC-0.03/PerlVINC.pm __ Stas BekmanJAm_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]
Re: porting Sandwich to mp2
Vivek Khera wrote: "SB" == Stas Bekman <[EMAIL PROTECTED]> writes: SB> modperl list... Also it's probably a good idea to ask the owner of SB> Apache::Sandwich whether they aren't working on a mp2 port already. I am not. Feel free to adopt it. Personally, I don't use it anymore in preference to a real templating system such as Template Toolkit. Thanks Vivek. So Ayhan it's all yours if you decide to adopt the name. __ Stas BekmanJAm_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]
Re: [PATCH] add PERL5LIB to @INC in the correct order
Simon Flack wrote:
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 some time soon (including the PERL5LIB fix). I know there
are quite a few patches that Philippe has planned to put in and we want
them to sit in the cvs for some time to get people time to test it out
well.
my advice would be to get 1.29 out soon, as it will be the first
stable version of mod_perl specifically for 5.8.1.
release 1.30 can come with those patches, and be released at a much
more leisurely pace
--Geoff
I'm happy with that. There's also another problem with PERL5LIB that I've
noticed, but not fixed because there's an easy workaround:
According to perlrun(1), architechture subfolders are added to @INC as well:
PERL5LIB
A colon-separated list of directories in which to look for
Perl library files before looking in the standard library
and the current directory. Any architecture-specific
directories under the specified locations are automatically
included if they exist.
For example on my dev box, setting PERL5LIB to '/home/simonflk/perllib'
should add '/home/simonflk/perllib/i686-linux' if it exists.
The simple and obvious workaround is to add that to PERL5LIB. But it would be
nice for it to behave as documented in perl. If the other fix to PERL5LIB is
scheduled for v1.30, it makes sense to fix that for the same release. When I
get some time I'll send in a patch.
OK, so 1.29 is out, we can put your patch in. Re: arch dirs, I think it's a
"recent" behavior (5.6x) and when that mp1 code was written (many years ago)
it wasn't there. So would you consider to submit a new patch that performs the
arch lookup as well and we will commit it at once?
My suggestion would be to simply use the lib pragma and delegate the job of
looking up the arch dirs to it. So all we need to do is :
use lib split /$separator/, $ENV{PERL5LIB};
though via C (you can use eval_pv to eval the above string).
__
Stas BekmanJAm_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]
Re: [PATCH] add PERL5LIB to @INC in the correct order
OK, so 1.29 is out, we can put your patch in.
I know I was +1 before, but now that we're all a bit more enlightened as to
PERL5LIB and its implications, I think we ought to reconsider.
my reasons against altering _anything_ about PERL5LIB behavior in 1.0 would be
- altering the existing, stable codebase for little benefit. nobody else
has reported using lib separators (":") or wanting arch libs included in,
what, 6+ years?
- we probably shouldn't be supporting it at all
just my $0.02. it's not a veto or anything, but I'm really hesitant to play
around with this simply because, even though the changes is simple, we still
may introduce bugs that hurt existing users of PERL5LIB. and that's not
good at this point.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] add PERL5LIB to @INC in the correct order
Geoffrey Young wrote:
OK, so 1.29 is out, we can put your patch in.
I know I was +1 before, but now that we're all a bit more enlightened as
to PERL5LIB and its implications, I think we ought to reconsider.
my reasons against altering _anything_ about PERL5LIB behavior in 1.0
would be
- altering the existing, stable codebase for little benefit. nobody
else has reported using lib separators (":") or wanting arch libs
included in, what, 6+ years?
- we probably shouldn't be supporting it at all
just my $0.02. it's not a veto or anything, but I'm really hesitant to
play around with this simply because, even though the changes is simple,
we still may introduce bugs that hurt existing users of PERL5LIB. and
that's not good at this point.
I'd be tempted to put that change in, exactly because nobody has complained so
far, which can be interpreted that nobody was relying on that feature or
questions would be raised.
In the mp1 guide: "Installation Without Superuser Privileges"
http://perl.apache.org/docs/1.0/guide/install.html#Installation_Without_Superuser_Privileges
The section:
"Making Your Scripts Find the Locally Installed Modules"
http://perl.apache.org/docs/1.0/guide/install.html#Making_Your_Scripts_Find_the_Locally_Installed_Modules
uses PERL5LIB with multiple entries and it explicitly specifies arch libs.
though the order of insertion didn't matter in that particular case.
Notice that if we use the lib pragma, it'll still do the right thing even if
PERL5LIB has already explicitly specified arch libs, as the guide suggestes.
I guess Simon could help us here as neither I have a strong opinion about this
change. Do you think, Simon, that we should change the existing behavior or
just document the way it works? Either way works for me.
__
Stas BekmanJAm_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]
Re: modperl_callback() guessing revisited
Geoffrey Young wrote:
hi all
in continuing the discussion from last week (or was it the week before)
where we decided to fix the PL_sv_undef thing first then re-examine
modperl_callback's second-guessing the return value of the Perl callback...
attached is a patch that fixes things to how I think they should work
-
-/* assume OK for non-HTTP status codes and for 200 (HTTP_OK) */
-if (((status > 0) && (status < 100)) ||
-(status == 200) || (status > 600)) {
-status = OK;
-}
So we remove any second-guessing, and require an explicit return as discussed
before. +1
__
Stas BekmanJAm_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]
Re: Testing and smoking leave a PID file behind
I've committed the latest version plus the cleanup suggested in the last email
of yours.
This only leaves the problem of it occasionally picking up the "wrong"
PID file:-
Anyway, I thought I'd add some code in try_exit_opts() to remove the
PID file, but it still didn't always work. I added more code to
print out the PID file that it was deleting and found that sometimes
it is the "wrong" one. Here's what I've added in try_exit_opts(),
just before the "exit_perl $ok" at the end of that function:
my $t_logs = $self->{test_config}->{vars}->{t_logs};
my $pid_file = catfile $t_logs, "httpd.pid";
open my $fh, ">C:\\Temp\\debug.txt";
print $fh "Removing PID file '$pid_file' ...\n";
close $fh;
unlink $pid_file if -e $pid_file;
It seems that whether or not this works depends on exactly when I
happen to press Ctrl+C. One time it said
Removing PID file 'C:\Temp\modperl-2.0\t\logs\httpd.pid' ...
and sure enough the PID file was gone, but another time it said
Removing PID file
'C:\Temp\modperl-2.0\docs\devel\core_explained\CVS\t\logs\httpd.pid' ...
and, of course, the main PID file
'C:\Temp\modperl-2.0\t\logs\httpd.pid' was left behind.
Now I haven't got a clue what's going on. Any ideas?
File::Find looks for core dumps after each execution. Perhaps you
Ctrl-C'ed it when it was inside docs\devel\core_explained?
Maybe, but...
Perhaps we need to expand vars like
$self->{test_config}->{vars}->{t_logs} to a full path, in which case
it won't be an issue?
... as you see from the output above the (wrong) PID file that it
deleted is fully-pathed anyway!
but that's a wrong full path. docs\devel\core_explained is not the top_dir,
meaning that somewhere we have a glitch and not using a fullpath.
Also this core files scan, is it relevant at all to WIN32? When you
get a coredump, do you get a core file?
No, there's no core files on Win32. "Dr Watson's log files" would be
the closest thing I suppose, but you don't really want to go there.
Perhaps if we skip the coredump scan on Win32 then the problem of the
"wrong" PID file being picked up would go away?
I suggest we first fix the problem of the wrong path, since it may bite us
elsewhere later.
Next please submit a patch to skip core_scan (there are two versions in
TestRun), which will make SMOKE much faster on win32.
__
Stas BekmanJAm_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]
Re: Testing and smoking leave a PID file behind
Stas Bekman wrote: Also this core files scan, is it relevant at all to WIN32? When you get a coredump, do you get a core file? No, there's no core files on Win32. "Dr Watson's log files" would be the closest thing I suppose, but you don't really want to go there. Perhaps if we skip the coredump scan on Win32 then the problem of the "wrong" PID file being picked up would go away? I suggest we first fix the problem of the wrong path, since it may bite us elsewhere later. Next please submit a patch to skip core_scan (there are two versions in TestRun), which will make SMOKE much faster on win32. Argh, looks like I should have waited for the wrong path issue fix, before committing the skip of the core_scan on win32. Applying a reversed patch of this should give you the previous state back: http://marc.theaimsgroup.com/?l=apache-test-cvs&m=106669945815816&w=2 __ Stas BekmanJAm_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]
Re: mod_perl 1.99_10 on AIX 5
Rafael Garcia-Suarez wrote:
Stas Bekman wrote:
mod_perl 1.99_10 on AIX 5.2 with the IBM vac compiler, using
perl 5.8.1 without ithreads, is mostly OK.
[...]
Here's the full test output :
$ t/TEST -v modperl/subenv
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST -v 'modperl/subenv'
consider removing an old /home/garcia/mod_perl-1.99_10/t/core file before running tests
/home/garcia/apache2prefork/bin/httpd -d /home/garcia/mod_perl-1.99_10/t -f /home/garcia/mod_perl-1.99_10/t/conf/httpd.conf -DAPACHE2
using Apache/2.0.47 (prefork MPM)
[...]
modperl/subenv1..16
[...]
FAILED tests 14-16
Failed 3/16 tests, 81.25% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
---
modperl/subenv.t 163 18.75% 14-16
*** server localhost:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
!!! oh jeez, server dumped core
!!! for stacktrace, run: gdb /home/garcia/apache2prefork/bin/httpd -core /home/garcia/mod_perl-1.99_10/t/core
So it segfaults when calling
$r->subprocess_env(FOO => 1);
at t/response/TestModperl/subenv.pm:34
which goes into C guts at WrapXS/Apache/RequestRec/RequestRec.c
#line 66 "RequestRec.xs"
RETVAL = mpxs_Apache__RequestRec_subprocess_env(aTHX_ r, key, val);
#line 117 "RequestRec.c"
ST(0) = RETVAL;
sv_2mortal(ST(0));
I'd check whether RETVAL is a valid sv. It gets its value from
modperl_table_get_set pasted next:
SV *modperl_table_get_set(pTHX_ apr_table_t *table, char *key,
SV *sv_val, int do_taint)
{
SV *retval = &PL_sv_undef;
if (table == NULL) {
/* do nothing */
}
else if (key == NULL) {
retval = modperl_hash_tie(aTHX_ "APR::Table",
Nullsv, (void*)table);
}
else if (!sv_val) { /* no val was passed */
char *val;
if ((val = (char *)apr_table_get(table, key))) {
retval = newSVpv(val, 0);
}
else {
retval = newSV(0);
}
if (do_taint) {
SvTAINTED_on(retval);
}
}
else if (!SvOK(sv_val)) { /* val was passed in as undef */
apr_table_unset(table, key);
}
else {
apr_table_set(table, key, SvPV_nolen(sv_val));
}
return retval;
}
Here's the backtrace :
(dbx) where
sig_coredump(sig = 11), line 367 in "prefork.c"
Perl_sv_2mortal() at 0xd40bac0c
XS_Apache__RequestRec_subprocess_env() at 0xd41fd9fc
Perl_pp_entersub() at 0xd4139a48
Perl_runops_standard() at 0xd41356fc
S_call_body() at 0xd40c37bc
Perl_call_sv() at 0xd40c7614
modperl_callback() at 0xd40a01b0
modperl_callback_run_handlers() at 0xd409fe80
modperl_callback_per_dir() at 0xd409fbcc
modperl_response_handler_run() at 0xd409e594
modperl_response_handler() at 0xd409f034
ap_run_handler(0x208065b8), line 194 in "config.c"
ap_invoke_handler(0x208065b8), line 401 in "config.c"
ap_process_request(0x208065b8), line 288 in "http_request.c"
ap_process_http_connection(0x20802670), line 293 in "http_core.c"
ap_run_process_connection(0x20802670), line 85 in "connection.c"
ap_process_connection(0x20802670, 0x20802598), line 211 in "connection.c"
child_main(child_num_arg = 1), line 694 in "prefork.c"
unnamed block $b272, line 788 in "prefork.c"
make_child(s = 0x20028b80, slot = 1), line 788 in "prefork.c"
perform_idle_server_maintenance(p = 0x20026470), line 923 in "prefork.c"
unnamed block $b276, line 1118 in "prefork.c"
ap_mpm_run(_pconf = 0x20026470, plog = 0x2005e630, s = 0x20028b80), line 1118 in
"prefork.c"
main(argc = 6, argv = 0x2ff22ac4), line 660 in "main.c"
I'm using httpd 2.0.47.
I suspect some portability nastiness with memory handing of
environment variables, but that's just an impression. I may have time
to dig further in some future.
I can't reproduce this problem, so if you can debug it that would be great.
For the future you probably want to build mod_perl with MP_MAINTAINER=1 and
MP_DEBUG=1 so that your stacktrace will show the arguments and line numbers as
well. Also throw in MP_TRACE=1, if you ever need to do tracing without
invoking debugger. This is of course good only for a non-production server.
__
Stas BekmanJAm_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]
