Re: early perl startup in vhost on win32
Stas Bekman wrote: Steve Hay wrote: At least I have found a sure way to verify that a segfault is caused by the wrong context. When you get a core trace where a Perl_ call, passing interpreter argument (my_perl on Unix, interpreter on win32), is followed by another Perl_ call, which doesn't pass this argument, go that that frame with the latter call and issue (gdb) p PL_curinterp if it doesn't match the interpreter (or my_perl) argument from the call one frame higher, you know what the problem is. Actually it's not necessarily true. Since interpreter/my_perl could be a perl from the pool, and PL_curinterp is always a parent perl. So you also need the trace to see what pointer the parent pool has. The opposite is true. If you get the same pointer for PL_curinterp and interpreter/my_perl, then the issue is elsewhere. In your trace: VMem::Free(void * 0x00acea1c) line 208 + 3 bytes CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302 Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes (gdb) p PL_curinterp Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 + 13 bytes (gdb) up (gdb) p interpreter if the two are not the same, the problem is clear. PL_curinterp is a true global variable, so it's impossible to maintain it per interpreter. The next step is to figure out how to set the perl context every time we select a new interepreter without incurring too much overhead and encapsulate this function together with the selector code so not to clutter the code and prevent forgetting to set the context in the newly added code. I will keep you posted. __ 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: early perl startup in vhost on win32
Stas Bekman wrote:
Steve Hay wrote:
At least I have found a sure way to verify that a segfault is caused
by the wrong context. When you get a core trace where a Perl_ call,
passing interpreter argument (my_perl on Unix, interpreter on win32),
is followed by another Perl_ call, which doesn't pass this argument,
go that that frame with the latter call and issue
(gdb) p PL_curinterp
if it doesn't match the interepreter (or my_perl) argument from the
call one frame higher, you know what the problem is. In your trace:
VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
(gdb) p PL_curinterp
Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 +
13 bytes
(gdb) up
(gdb) p interpreter
if the two are not the same, the problem is clear.
I can't do _exactly_ what you've written above (I'm using MSVC++ rather
than gdb), but I can watch the value of any visible variables within
each frame. If I'm doing this correctly then I don't actually see the
problem that you describe. The value of interpreter isn't shown by
MSVC++ in the watch window (it just gives me {...}!) but I guess you
can see it from the stacktrace itself. Here's the stacktrace for for
what I'm looking at now:
VMem::Free(void * 0x009fb864) line 208 + 3 bytes
CPerlHost::Free(void * 0x009fb864) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x009fb864) line 302
Perl_safesysfree(void * 0x009fb864) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13
bytes
Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13 bytes
Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643cc) line 146 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x00924db0) line 128 + 12 bytes
modperl_interp_pool_destroy(void * 0x00851398) line 184 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0028a9e8) line 715 + 12 bytes
main(int 7, const char * const * 0x00282908) line 619
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
So interpreter is 0x002643cc in the calls to modperl_perl_destruct()
through to Perl_sv_clear(). Here's what the watch window shows me for
the values of PL_curinterp and my_perl in each of those frames and the
later frames as well:
VMem::Free()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
CPerlHost::Free()
PL_curinterp: 0x002643cc
my_perl: Error: symbol my_perl not found
PerlMemFree()
PL_curinterp: 0x002643cc
my_perl: Error: symbol my_perl not found
Perl_safesysfree()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
Perl_sv_clear()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
Perl_sv_free()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
Perl_free_tmps()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
perl_destruct()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
modperl_perl_destruct()
PL_curinterp: Error: symbol PL_curinterp not found
my_perl: 0x002643cc
In particular, the PL_curinterp value within the Perl_safesysfree()
frame (which didn't get the interpreter passed) is the same as the
my_perl value within the Perl_sv_clear() frame (which did get the
interpreter passed).
- Steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: early perl startup in vhost on win32
Steve Hay wrote:
Stas Bekman wrote:
Steve Hay wrote:
At least I have found a sure way to verify that a segfault is caused
by the wrong context. When you get a core trace where a Perl_ call,
passing interpreter argument (my_perl on Unix, interpreter on win32),
is followed by another Perl_ call, which doesn't pass this argument,
go that that frame with the latter call and issue
(gdb) p PL_curinterp
if it doesn't match the interepreter (or my_perl) argument from the
call one frame higher, you know what the problem is. In your trace:
VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
(gdb) p PL_curinterp
Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 +
13 bytes
(gdb) up
(gdb) p interpreter
if the two are not the same, the problem is clear.
I can't do _exactly_ what you've written above (I'm using MSVC++ rather
than gdb), but I can watch the value of any visible variables within
each frame. If I'm doing this correctly then I don't actually see the
problem that you describe. The value of interpreter isn't shown by
MSVC++ in the watch window (it just gives me {...}!) but I guess you
can see it from the stacktrace itself. Here's the stacktrace for for
what I'm looking at now:
VMem::Free(void * 0x009fb864) line 208 + 3 bytes
CPerlHost::Free(void * 0x009fb864) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x009fb864) line 302
Perl_safesysfree(void * 0x009fb864) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13
bytes
Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13
bytes
Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643cc) line 146 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x00924db0) line 128 + 12 bytes
modperl_interp_pool_destroy(void * 0x00851398) line 184 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0028a9e8) line 715 + 12 bytes
main(int 7, const char * const * 0x00282908) line 619
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
So interpreter is 0x002643cc in the calls to modperl_perl_destruct()
through to Perl_sv_clear(). Here's what the watch window shows me for
the values of PL_curinterp and my_perl in each of those frames and the
later frames as well:
VMem::Free()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
[...]
only the last one matters.
In particular, the PL_curinterp value within the Perl_safesysfree()
frame (which didn't get the interpreter passed) is the same as the
my_perl value within the Perl_sv_clear() frame (which did get the
interpreter passed).
That's a bad news. In which case I don't know what the problem is on your
side. Though we did see that messing with setting of the context helps things,
so we might be still around the right track.
Since I can reproduce segfaults and I do get different values for PL_curinterp
and the passed my_perl, I'll first tackle that one. And then we will get back
to try to figure out what's wrong is 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]
[Fwd: 5.8.2 RC1]
hi all... time to start testing a new perl release candidate. note that mod_perl is specifically mentioned under 'particular interests' :) last night, everything passed for me with RC1 except 2.0-worker, which got this error: [Tue Oct 28 04:51:10 2003] [error] lookup of 'Apache::PerlSections::handler' failed Syntax error on line 25 of /src/mod_perl-2.0/t/conf/extra.last.conf: Perl handler Apache::PerlSections failed with status=500 still looking into it. --Geoff Original Message Subject: 5.8.2 RC1 Date: Mon, 27 Oct 2003 23:49:28 + From: Nicholas Clark [EMAIL PROTECTED] To: [EMAIL PROTECTED] They went to sea in a Sieve, they did, In a Sieve they went to sea: In spite of all their friends could say, On a winter's morn, on a stormy day, In a Sieve they went to sea! And when the Sieve turned round and round, And everyone cried, You'll all be drowned! They cried aloud, Our Sieve ain't big, But we don't care a button, we don't care a fig! In a Sieve we'll go to sea! Far and few, far and few, Are the lands where the Jumblies live; Their heads are green, and their hands are blue, And they went to sea in a Sieve. (The Jumblies - Edward Lear) Well, here is our very own sea-going sieve. :-) Please test it thoroughly and find all the holes *before* we set sail. http://www.cpan.org/authors/id/N/NW/NWCLARK/perl-5.8.2-RC1.tar.bz2 Once it's propagated round the CPAN mirrors I'll make an announcement on use.perl I'm particularly interested in 0: binary compatibility between 5.8.2 and modules compiled under 5.8.0 1: binary compatibility between 5.8.2 and modules compiled under 5.8.1 2: how scripts that hash large amounts of data behave 3: reassurance that it still build on Windows, VMS, OS/2, ... 4: whether OS X and Solaris build all XS modules correctly now 5: is modperl still happy 6: does PAR work smoothly I suspect that I've forgotten something important from that list rsync ftp.linux.activestate.com::perl-5.8.x/ will be at RC1 for the next 16 hours or so. Nicholas Clark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r-finfo on $r-filename($newfile)
what it really does, is manipulating an internal Apache struct, hence
I suggested to have a tracing option which will show only traces that
affect Apache internal structs. e.g. tracing the mod of document_root
sounds like a good example which will fit the MP_TRACE_a category
ok, MP_TRACE_a it is, then.
actually, I kind of like it - if we use it for places where we add
logic behind what would otherwise be raw ap* calls, that would be very
nice to have.
cool.
cool++
patch attached.
--Geoff
Index: lib/ModPerl/Code.pm
===
RCS file: /home/cvspublic/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.112
diff -u -r1.112 Code.pm
--- lib/ModPerl/Code.pm 23 Oct 2003 19:46:42 - 1.112
+++ lib/ModPerl/Code.pm 28 Oct 2003 15:59:42 -
@@ -451,7 +451,7 @@
}
my %trace = (
-#'a' = 'all',
+'a' = 'Apache API interaction',
'c' = 'configuration for directive handlers',
'd' = 'directive processing',
'e' = 'environment variables',
@@ -481,13 +481,13 @@
#define MP_TRACE_OPTS $opts
#ifdef MP_TRACE
-#define MP_TRACE_a if ($tl) modperl_trace
-#define MP_TRACE_a_do(exp) if ($tl) { \\
+#define MP_TRACE_any if ($tl) modperl_trace
+#define MP_TRACE_any_do(exp) if ($tl) { \\
exp; \\
}
#else
-#define MP_TRACE_a if (0) modperl_trace
-#define MP_TRACE_a_do(exp)
+#define MP_TRACE_any if (0) modperl_trace
+#define MP_TRACE_any_do(exp)
#endif
EOF
Index: src/modules/perl/modperl_log.c
===
RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_log.c,v
retrieving revision 1.9
diff -u -r1.9 modperl_log.c
--- src/modules/perl/modperl_log.c 23 Sep 2003 08:04:42 - 1.9
+++ src/modules/perl/modperl_log.c 28 Oct 2003 15:59:42 -
@@ -74,5 +74,5 @@
modperl_trace_logfile_set(s-error_log);
-MP_TRACE_a_do(MP_TRACE_dump_flags());
+MP_TRACE_any_do(MP_TRACE_dump_flags());
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r-finfo on $r-filename($newfile)
Geoffrey Young wrote:
[...]
Index: lib/ModPerl/Code.pm
===
RCS file: /home/cvspublic/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.112
diff -u -r1.112 Code.pm
--- lib/ModPerl/Code.pm 23 Oct 2003 19:46:42 - 1.112
+++ lib/ModPerl/Code.pm 28 Oct 2003 15:59:42 -
@@ -451,7 +451,7 @@
}
my %trace = (
-#'a' = 'all',
+'a' = 'Apache API interaction',
Ah, sorry, I forgot that 'a' is taken by 'all'. I can't think of another good
choice. In which case how about 'p' for aPache?
'c' = 'configuration for directive handlers',
'd' = 'directive processing',
'e' = 'environment variables',
@@ -481,13 +481,13 @@
#define MP_TRACE_OPTS $opts
#ifdef MP_TRACE
-#define MP_TRACE_a if ($tl) modperl_trace
-#define MP_TRACE_a_do(exp) if ($tl) { \\
+#define MP_TRACE_any if ($tl) modperl_trace
+#define MP_TRACE_any_do(exp) if ($tl) { \\
exp; \\
}
#else
-#define MP_TRACE_a if (0) modperl_trace
-#define MP_TRACE_a_do(exp)
+#define MP_TRACE_any if (0) modperl_trace
+#define MP_TRACE_any_do(exp)
#endif
EOF
Index: src/modules/perl/modperl_log.c
===
RCS file: /home/cvspublic/modperl-2.0/src/modules/perl/modperl_log.c,v
retrieving revision 1.9
diff -u -r1.9 modperl_log.c
--- src/modules/perl/modperl_log.c 23 Sep 2003 08:04:42 - 1.9
+++ src/modules/perl/modperl_log.c 28 Oct 2003 15:59:42 -
@@ -74,5 +74,5 @@
modperl_trace_logfile_set(s-error_log);
-MP_TRACE_a_do(MP_TRACE_dump_flags());
+MP_TRACE_any_do(MP_TRACE_dump_flags());
So, did you change s/all/any/?
__
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: updating r-finfo on $r-filename($newfile)
my %trace = ( -#'a' = 'all', +'a' = 'Apache API interaction', Ah, sorry, I forgot that 'a' is taken by 'all'. I can't think of another good choice. In which case how about 'p' for aPache? actually, I thought all was 'a' too, but it doesn't look that way. if I do a preamble 'PerlTrace a' I don't get anything, and MP_TRACE_a only exists in 1 place (below). 'all' is mapped to MP_debug_level 0x -MP_TRACE_a_do(MP_TRACE_dump_flags()); +MP_TRACE_any_do(MP_TRACE_dump_flags()); So, did you change s/all/any/? this is the only occurence. I think MP_TRACE_a (and the above variant) designates tracing that should happen as long as there is _some_ (or 'any' :) trace enabled. the autogenerated code (current) looks like this #define MP_TRACE_OPTS cdefghimost #define MP_TRACE_a if (MP_debug_level) modperl_trace #define MP_TRACE_c if (MP_debug_level 1) modperl_trace so, I took over 'a' and changed the only _a to _any. I think it's a bit better this way but if you want to use 'p' instead, that's fine. it's no biggie. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
MP_APXS vs MP_AP_PREFIX
hi all the docs say MP_APXS may go away, but I recall some discussion to the contrary. has the status of MP_APXS changed? I can't recall the exact reason why, but a while ago I switched to MP_APXS because I couldn't get MP_AP_PREFIX to work properly on muliple build environments. the reason I'm asking is because I've started looking at Apache::BuildConfig to see if there isn't a way to make it versioned for muliple installs. I know we talked about this before, but IIRC it was in a different context. the thing that's bugging me today is this [EMAIL PROTECTED] Apache-IncludeHook]$ perl Makefile.PL -apxs /apache/2.1/worker/perl-5.8.1/bin/apxs ... [EMAIL PROTECTED] Apache-IncludeHook]$ make ... cc -c -I/apache/2.0/worker/perl-5.8.1/include what I'd like is for ModPerl::MM::WriteMakefile to be able to pick up command like arguments from filter_args, then have Apache::BuildConfig use the same options that I used when MP_APXS=/apache/2.1/worker/perl-5.8.1/bin/apxs a lot to ask, I know :) so, any ideas as to an approach? --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r-finfo on $r-filename($newfile)
Geoffrey Young wrote: my %trace = ( -#'a' = 'all', +'a' = 'Apache API interaction', Ah, sorry, I forgot that 'a' is taken by 'all'. I can't think of another good choice. In which case how about 'p' for aPache? actually, I thought all was 'a' too, but it doesn't look that way. if I do a preamble 'PerlTrace a' I don't get anything, and MP_TRACE_a only exists in 1 place (below). 'all' is mapped to MP_debug_level 0x -MP_TRACE_a_do(MP_TRACE_dump_flags()); +MP_TRACE_any_do(MP_TRACE_dump_flags()); So, did you change s/all/any/? this is the only occurence. I think MP_TRACE_a (and the above variant) designates tracing that should happen as long as there is _some_ (or 'any' :) trace enabled. the autogenerated code (current) looks like this #define MP_TRACE_OPTS cdefghimost #define MP_TRACE_a if (MP_debug_level) modperl_trace #define MP_TRACE_c if (MP_debug_level 1) modperl_trace so, I took over 'a' and changed the only _a to _any. I think it's a bit better this way but if you want to use 'p' instead, that's fine. it's no biggie. Thanks Geoff. I looked some more at it: We have 'all' which sets all levels and it won't clash with 'a'. We have 'any' which is set when any level is set (coded as _a, you changed it to _any which is even better). So I think your original patch is just fine. +1 to commit, perhaps committing it in parts (_a = _any first, then adding support for 'a'). __ 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: MP_APXS vs MP_AP_PREFIX
Geoffrey Young wrote: hi all the docs say MP_APXS may go away, but I recall some discussion to the contrary. has the status of MP_APXS changed? do they? I think it's quite the opposite now and I have updated the docs. I guess I've missed some places, please tell me where. Now that Randy has added APXS for win32, we don't need MP_AP_PREFIX for the DSO build. Though we will need it for the static build, so both are here to stay. I can't recall the exact reason why, but a while ago I switched to MP_APXS because I couldn't get MP_AP_PREFIX to work properly on muliple build environments. the reason I'm asking is because I've started looking at Apache::BuildConfig to see if there isn't a way to make it versioned for muliple installs. I know we talked about this before, but IIRC it was in a different context. the thing that's bugging me today is this [EMAIL PROTECTED] Apache-IncludeHook]$ perl Makefile.PL -apxs /apache/2.1/worker/perl-5.8.1/bin/apxs ... [EMAIL PROTECTED] Apache-IncludeHook]$ make ... cc -c -I/apache/2.0/worker/perl-5.8.1/include ^^^ why is it 2.0? and not 2.1? Are you sure that /apache/2.1/worker/perl-5.8.1/bin/apxs doesn't' have 2.0 paths in it? what I'd like is for ModPerl::MM::WriteMakefile to be able to pick up command like arguments from filter_args, then have Apache::BuildConfig use the same options that I used when MP_APXS=/apache/2.1/worker/perl-5.8.1/bin/apxs a lot to ask, I know :) so, any ideas as to an approach? I don't understand the problem clearly, MP::MM::WM is using A::BuildConfig to get its data, so it's already aware of the command line args, no? __ 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: MP_APXS vs MP_AP_PREFIX
Stas Bekman wrote:
Geoffrey Young wrote:
hi all
the docs say MP_APXS may go away, but I recall some discussion to the
contrary. has the status of MP_APXS changed?
do they? I think it's quite the opposite now and I have updated the
docs. I guess I've missed some places, please tell me where.
I was looking at
http://perl.apache.org/docs/2.0/user/install/install.html#MP_APXS
Now that Randy has added APXS for win32, we don't need MP_AP_PREFIX for
the DSO build. Though we will need it for the static build, so both are
here to stay.
ok
[EMAIL PROTECTED] Apache-IncludeHook]$ perl Makefile.PL -apxs
/apache/2.1/worker/perl-5.8.1/bin/apxs
...
[EMAIL PROTECTED] Apache-IncludeHook]$ make
...
cc -c -I/apache/2.0/worker/perl-5.8.1/include
^^^
why is it 2.0? and not 2.1?
that's the problem I'm addressing
Are you sure that
/apache/2.1/worker/perl-5.8.1/bin/apxs doesn't' have 2.0 paths in it?
yup. I take lots of steps to make sure there is no overlap in any of my
builds - each variant gets a clean copy of httpd-2.0 to work with and
everything is truncated nightly.
I don't understand the problem clearly, MP::MM::WM is using
A::BuildConfig to get its data, so it's already aware of the command
line args, no?
that's just it, WM doesn't seem to be picking up data parsed via
Apache::TestMM::filter_args(). but even if it did, the only data in
Apache::BuildConfig is from the mod_perl I installed last (which is the 2.0
install you see in -I above).
what I was thinking about doing was instead of BuildConfig doing
sub new {
bless( {
'MODPERL_PRIVLIBEXP' = '/perl/perl-5.8.1/lib/5.8.1',
it could do
sub new {
bless( '/apache/2.1/worker/perl-5.8.1/' = {
'MODPERL_PRIVLIBEXP' = '/perl/perl-5.8.1/lib/5.8.1',
...
'/apache/2.0/worker/perl-5.8.1/' = {
'MODPERL_PRIVLIBEXP' = '/perl/perl-5.8.1/lib/5.8.1',
instead. the issue is, though, what to use as the key. my thought was to
truncate either MP_APXS or MP_AP_PREFIX to the apache install root and use
that as the key. or maybe 'default' as the key the first time, and
subsequent installs get versioned or something.
is the problem still unclear? I can try to illustrate it better if need be.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: MP_APXS vs MP_AP_PREFIX
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
hi all
the docs say MP_APXS may go away, but I recall some discussion to the
contrary. has the status of MP_APXS changed?
do they? I think it's quite the opposite now and I have updated the
docs. I guess I've missed some places, please tell me where.
I was looking at
http://perl.apache.org/docs/2.0/user/install/install.html#MP_APXS
Thanks. Fixed (removed that META comment).
Now that Randy has added APXS for win32, we don't need MP_AP_PREFIX
for the DSO build. Though we will need it for the static build, so
both are here to stay.
ok
[EMAIL PROTECTED] Apache-IncludeHook]$ perl Makefile.PL -apxs
/apache/2.1/worker/perl-5.8.1/bin/apxs
...
[EMAIL PROTECTED] Apache-IncludeHook]$ make
...
cc -c -I/apache/2.0/worker/perl-5.8.1/include
^^^
why is it 2.0? and not 2.1?
that's the problem I'm addressing
Are you sure that /apache/2.1/worker/perl-5.8.1/bin/apxs doesn't' have
2.0 paths in it?
yup. I take lots of steps to make sure there is no overlap in any of my
builds - each variant gets a clean copy of httpd-2.0 to work with and
everything is truncated nightly.
I don't understand the problem clearly, MP::MM::WM is using
A::BuildConfig to get its data, so it's already aware of the command
line args, no?
that's just it, WM doesn't seem to be picking up data parsed via
Apache::TestMM::filter_args(). but even if it did, the only data in
Apache::BuildConfig is from the mod_perl I installed last (which is the
2.0 install you see in -I above).
what I was thinking about doing was instead of BuildConfig doing
sub new {
bless( {
'MODPERL_PRIVLIBEXP' = '/perl/perl-5.8.1/lib/5.8.1',
it could do
sub new {
bless( '/apache/2.1/worker/perl-5.8.1/' = {
'MODPERL_PRIVLIBEXP' = '/perl/perl-5.8.1/lib/5.8.1',
...
'/apache/2.0/worker/perl-5.8.1/' = {
'MODPERL_PRIVLIBEXP' = '/perl/perl-5.8.1/lib/5.8.1',
instead. the issue is, though, what to use as the key. my thought was
to truncate either MP_APXS or MP_AP_PREFIX to the apache install root
and use that as the key. or maybe 'default' as the key the first time,
and subsequent installs get versioned or something.
is the problem still unclear? I can try to illustrate it better if need
be.
No, I understand it now. I think the unique value you are after is the path to
httpd, including httpd (for those distros moving it to /usr/bin).
Though you are going to have a hard time maintaining several configs in one
file. Instead it's probably better to abstract those into separate files, so
when you add a new build you don't need to update that file but only install
new build. I was thinking to use an approach taken by Inline, when it builds
the shared library. It uses an MD5 hash of the C source as a part of the
filename. So when the source changes it knows to rebuild it. We could take an
MD5 hash of the path to httpd. Then create:
BuildConfig-16128e67ad092a739842b82295820e31.pm
BuildConfig-938883be41ad5efc6c9c0d7affdae8e9.pm
for each build (2 builds above).
Next, when Apache::BuildConfig loads, it could optionally get the http
argument, calculate its md5 hash and pick the right BuildConfig file above.
We also need:
BuildConfig-default.pm
which will store the first build, in case the path to httpd is not passed
(that's what most users will want: just use my mp2 build data.
The problem is that MD5 modules aren't in the core. But 99.% of users
won't need this feature, so if we can make it optional (or e.g. when
MP_MAINTAINER is on).
may be keeping Apache::BuildConfig as it is now, but instrument it to
optionally check for these special files, which will be useful for developers.
__
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: MP_APXS vs MP_AP_PREFIX
On Tue, 28 Oct 2003, Stas Bekman wrote: Now that Randy has added APXS for win32, we don't need MP_AP_PREFIX for the DSO build. Though we will need it for the static build, so both are here to stay. It's not critical at this stage, but the Win32 apxs needs a manual download/install, so not all users will have it. At one point Bill Rowe was thinking of including it in httpd, but that hasn't happened yet. -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: MP_APXS vs MP_AP_PREFIX
No, I understand it now. I think the unique value you are after is the path to httpd, including httpd (for those distros moving it to /usr/bin). Though you are going to have a hard time maintaining several configs in one file. Instead it's probably better to abstract those into separate files, so when you add a new build you don't need to update that file but only install new build. I was thinking to use an approach taken by Inline, when it builds the shared library. It uses an MD5 hash of the C source as a part of the filename. So when the source changes it knows to rebuild it. We could take an MD5 hash of the path to httpd. Then create: BuildConfig-16128e67ad092a739842b82295820e31.pm BuildConfig-938883be41ad5efc6c9c0d7affdae8e9.pm where the hash is httpd run through md5? sick. I like it :) for each build (2 builds above). Next, when Apache::BuildConfig loads, it could optionally get the http argument, calculate its md5 hash and pick the right BuildConfig file above. We also need: BuildConfig-default.pm which will store the first build, in case the path to httpd is not passed (that's what most users will want: just use my mp2 build data. what might work is installing both BuildConfig.pm and BuildConfig-$hash.pm. BuildConfig would work as it does presently (containing the most-recent install data) and would be there for back compat (new WriteMakefile vs old mod_perl). The problem is that MD5 modules aren't in the core. they are in 5.8.0. not sure about 5.6.x. but I thought we made the decision to move to 5.8.0 once 5.8.1 came out. I can't remember, though. But 99.% of users won't need this feature, so if we can make it optional (or e.g. when MP_MAINTAINER is on). I agree, most people won't care about this, so making it optional at build time is best. may be keeping Apache::BuildConfig as it is now, but instrument it to optionally check for these special files, which will be useful for developers. optional both at mod_perl build time and an 3rd party module build time? I'd like to think that we can make this work so that mod_perl does the right thing - if mod_perl was built with the md5 versioning, then WriteMakefile does the right thing (or as close as we can get). how about MP_VERSIONED_BUILD=1 for the mod_perl end? --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[mp1] test suite is borked without LWP
Philippe, can you please look at this issue with mp1 test suite:
If LWP is not available, test suite fails to run (bug #1), but returns true
(bug #2), so 'make test make install' installs nevertheless. Moreover 'make
install goes again into src/modules and recompiles a few .c files (bug #3).
The last one could be an apache build bug, as the target timestamps aren't
updated.
Here is the log with perl 5.6.2:
perl Makefile.PL ...
make
make test make install
cp t/conf/mod_perl_srm.conf t/conf/srm.conf
../apache-1.3/src/httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t
httpd listening on port 8529
will write error_log to: t/logs/error_log
letting apache warm up...\c
done
/home/stas/perl/5.6.2/bin/perl t/TEST 0
Can't locate LWP/UserAgent.pm in @INC (@INC contains: ../blib/lib ../blib/arch
/home/stas/perl/5.6.2/lib/5.6.2/i686-linux /home/stas/perl/5.6.2/lib/5.6.2
/home/stas/perl/5.6.2/lib/site_perl/5.6.2/i686-linux
/home/stas/perl/5.6.2/lib/site_perl/5.6.2 /home/stas/perl/5.6.2/lib/site_perl
../.) at t/TEST line 48.
I still can't find LWP::UserAgent, try:
/home/stas/perl/5.6.2/bin/perl -MCPAN -e install q{LWP}
or
http://www.perl.com/cgi-bin/cpan_mod?module=LWP
Must skip important tests without LWP...
kill `cat t/logs/httpd.pid`
rm -f t/logs/httpd.pid
rm -f t/logs/error_log
(cd ../apache-1.3 PERL5LIB=/home/stas/apache.org/modperl/lib: make)
make[1]: Entering directory `/home/stas/apache.org/apache-1.3'
=== src
make[2]: Entering directory `/home/stas/apache.org/apache-1.3'
make[3]: Entering directory `/home/stas/apache.org/apache-1.3/src'
=== src/regex
make[4]: Nothing to be done for `all'.
=== src/regex
=== src/os/unix
make[4]: Nothing to be done for `all'.
=== src/os/unix
=== src/ap
make[4]: Nothing to be done for `all'.
=== src/ap
=== src/main
make[4]: Nothing to be done for `all'.
=== src/main
=== src/lib
=== src/lib
=== src/modules
=== src/modules/standard
make[5]: Nothing to be done for `all'.
=== src/modules/standard
=== src/modules/proxy
make[5]: Nothing to be done for `all'.
=== src/modules/proxy
=== src/modules/perl
make[5]: Nothing to be done for `all'.
=== src/modules/perl
=== src/modules
cc -c -I. -I/home/stas/perl/5.6.2/lib/5.6.2/i686-linux/CORE -I./os/unix
-I./include -DLINUX=22 -I/usr/include/db1 -DMOD_PERL -DUSE_PERL_SSI
-DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-DUSE_HSREGEX -DNO_DL_NEEDED -DDEBUGGING -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -DPERL_DESTRUCT_LEVEL=2
`./apaci` modules.c
cc -c -I. -I/home/stas/perl/5.6.2/lib/5.6.2/i686-linux/CORE -I./os/unix
-I./include -DLINUX=22 -I/usr/include/db1 -DMOD_PERL -DUSE_PERL_SSI
-DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-DUSE_HSREGEX -DNO_DL_NEEDED -DDEBUGGING -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g -DPERL_DESTRUCT_LEVEL=2
`./apaci` buildmark.c
cc -DLINUX=22 -I/usr/include/db1 -DMOD_PERL -DUSE_PERL_SSI -DDEBUGGING
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX
-DNO_DL_NEEDED -DDEBUGGING -fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -g -DPERL_DESTRUCT_LEVEL=2 `./apaci`\
-o httpd buildmark.o modules.o modules/standard/libstandard.a
modules/proxy/libproxy.a modules/perl/libperl.a main/libmain.a
./os/unix/libos.a ap/libap.a regex/libregex.a -lm -lcrypt -ldb1 -rdynamic
-Wl,-rpath,/home/stas/perl/5.6.2/lib/5.6.2/i686-linux/CORE -L/usr/local/lib
/home/stas/perl/5.6.2/lib/5.6.2/i686-linux/auto/DynaLoader/DynaLoader.a
-L/home/stas/perl/5.6.2/lib/5.6.2/i686-linux/CORE -lperl -lnsl -ldl -lm -lc
-lcrypt -lutil
modules/proxy/libproxy.a(proxy_cache.o)(.text+0x2bed): In function
`ap_proxy_cache_update':
/home/stas/apache.org/apache-1.3/src/modules/proxy/proxy_cache.c:1624: the use
of `mktemp' is dangerous, better use `mkstemp'
make[3]: Leaving directory `/home/stas/apache.org/apache-1.3/src'
make[2]: Leaving directory `/home/stas/apache.org/apache-1.3'
make[2]: Entering directory `/home/stas/apache.org/apache-1.3'
=== src/support
make[3]: Entering directory `/home/stas/apache.org/apache-1.3/src/support'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/stas/apache.org/apache-1.3/src/support'
=== src/support
make[2]: Leaving directory `/home/stas/apache.org/apache-1.3'
=== src
make[1]: Leaving directory `/home/stas/apache.org/apache-1.3'
make[1]: Entering directory `/home/stas/apache.org/modperl/Apache'
make[1]: Leaving directory `/home/stas/apache.org/modperl/Apache'
make[1]: Entering directory `/home/stas/apache.org/modperl/Connection'
make[1]: Leaving directory `/home/stas/apache.org/modperl/Connection'
make[1]: Entering directory `/home/stas/apache.org/modperl/Constants'
make[1]: Leaving directory `/home/stas/apache.org/modperl/Constants'
make[1]: Entering directory `/home/stas/apache.org/modperl/File'
make[1]: Leaving directory `/home/stas/apache.org/modperl/File'
make[1]: Entering directory
Re: [Fwd: 5.8.2 RC1]
Geoffrey Young wrote: hi all... time to start testing a new perl release candidate. Not yet. I'll commit shortly a change that won't do the seed mungling we did for 5.8.1. note that mod_perl is specifically mentioned under 'particular interests' :) heh. last night, everything passed for me with RC1 except 2.0-worker, which got this error: [Tue Oct 28 04:51:10 2003] [error] lookup of 'Apache::PerlSections::handler' failed Yup, I saw this and a few other random failures. You are probably not running 5.9.0 tests I get heaps of broken tests in both mp1 and mp2, haven't looked at the details yet. __ 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: MP_APXS vs MP_AP_PREFIX
Geoffrey Young wrote: No, I understand it now. I think the unique value you are after is the path to httpd, including httpd (for those distros moving it to /usr/bin). Though you are going to have a hard time maintaining several configs in one file. Instead it's probably better to abstract those into separate files, so when you add a new build you don't need to update that file but only install new build. I was thinking to use an approach taken by Inline, when it builds the shared library. It uses an MD5 hash of the C source as a part of the filename. So when the source changes it knows to rebuild it. We could take an MD5 hash of the path to httpd. Then create: BuildConfig-16128e67ad092a739842b82295820e31.pm BuildConfig-938883be41ad5efc6c9c0d7affdae8e9.pm where the hash is httpd run through md5? sick. I like it :) oh, you understood it as if I was suggesting to run md5sub on the actual binary? No, no, it's a bad idea. It's perfectly OK to rebuild httpd, without rebuilding mod_perl and suddently your hash won't match (if httpd has changed a bit) and you will have no config at all. I've suggested to md5sum the full path to httpd. for each build (2 builds above). Next, when Apache::BuildConfig loads, it could optionally get the http argument, calculate its md5 hash and pick the right BuildConfig file above. We also need: BuildConfig-default.pm which will store the first build, in case the path to httpd is not passed (that's what most users will want: just use my mp2 build data. what might work is installing both BuildConfig.pm and BuildConfig-$hash.pm. BuildConfig would work as it does presently (containing the most-recent install data) and would be there for back compat (new WriteMakefile vs old mod_perl). +1 The problem is that MD5 modules aren't in the core. they are in 5.8.0. not sure about 5.6.x. but I thought we made the decision to move to 5.8.0 once 5.8.1 came out. I can't remember, though. since it's a maintainer feature we should make this requirement transparent to the normal user (i.e. do this extra work only for MP_MAINTAINER=1) may be keeping Apache::BuildConfig as it is now, but instrument it to optionally check for these special files, which will be useful for developers. optional both at mod_perl build time and an 3rd party module build time? I'd like to think that we can make this work so that mod_perl does the right thing - if mod_perl was built with the md5 versioning, then WriteMakefile does the right thing (or as close as we can get). You forget that you need to pass the locaion of httpd so it'll choose the right md5sum. Otherwise it's a chiken and an egg problem. Users should have an exact same behavior as it is now. Only if the special mode is used, and a path to httpd is passed and there is a matching md5sum, then use the other config. how about MP_VERSIONED_BUILD=1 for the mod_perl end? +0. I'd stick to MP_MAINTAINER=1 and only add new features if we really have a need for it. So far I don't see normal users installing 2.1 on their machines along with 2.0. We can always add it later if the need arises. __ 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: MP_APXS vs MP_AP_PREFIX
Randy Kobes wrote: On Tue, 28 Oct 2003, Stas Bekman wrote: Now that Randy has added APXS for win32, we don't need MP_AP_PREFIX for the DSO build. Though we will need it for the static build, so both are here to stay. It's not critical at this stage, but the Win32 apxs needs a manual download/install, so not all users will have it. At one point Bill Rowe was thinking of including it in httpd, but that hasn't happened yet. You need to nudge Bill once a week or so if you want this to happen. Bill told me that he is very good at multitasking and the most tasks you give to him, the better the throughput. Right Bill? In any case, we aren't abolishing AP_PREFIX. __ 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: [Fwd: 5.8.2 RC1]
last night, everything passed for me with RC1 except 2.0-worker, which got this error: [Tue Oct 28 04:51:10 2003] [error] lookup of 'Apache::PerlSections::handler' failed Yup, I saw this and a few other random failures. random is right - I've seen a few others since then You are probably not running 5.9.0 tests I get heaps of broken tests in both mp1 and mp2, haven't looked at the details yet. I run against bleedperl nightly, but I never pay attention to those results. probably time to since 5.9.0 was announced, though. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: 5.8.2 RC1]
Geoffrey Young wrote: last night, everything passed for me with RC1 except 2.0-worker, which got this error: [Tue Oct 28 04:51:10 2003] [error] lookup of 'Apache::PerlSections::handler' failed Yup, I saw this and a few other random failures. random is right - I've seen a few others since then Which is a very bad sign ;( __ 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: [Fwd: 5.8.2 RC1]
Stas Bekman wrote: Geoffrey Young wrote: last night, everything passed for me with RC1 except 2.0-worker, which got this error: [Tue Oct 28 04:51:10 2003] [error] lookup of 'Apache::PerlSections::handler' failed Yup, I saw this and a few other random failures. random is right - I've seen a few others since then Which is a very bad sign ;( Make sure that you run with PERL_HASH_SEED_DEBUG=1 and PassEnv PERL_HASH_SEED_DEBUG, and record those failing seeds. Then feed them back with: PERL_HASH_SEED=$seed and PassEnv PERL_HASH_SEED and hopefully you will be able to reproduce them. __ 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: Useless use of a constant in void context at Makefile.PL line 467
Stas Bekman wrote:
Carl Brewer wrote:
Stas Bekman wrote:
So the offending line is:
$string .= Apache::Test::install::nuke_Apache__test_target()
if APACHE_TEST_INSTALL();
You lost the actual constant that it was complaining about ;) I
should have looked closer.
Any change if you replace it with:
if (APACHE_TEST_INSTALL()) {
$string .= Apache::Test::install::nuke_Apache__test_target();
}
Nope, same error.
OK, what happens if you replace that line with:
print APACHE_TEST_INSTALL ? APACHE_TEST_INSTALL : NOT
APACHE_TEST_INSTALL;
$string .= Apache::Test::install::nuke_Apache__test_target();
does it complain about the print line, or the $string one?
It's complainign abuot the test line :
if (APACHE_TEST_INSTALL()) {
Also what happens if you change
BEGIN {
use constant APACHE_TEST_INSTALL = -e 'Apache-Test';
use lib './Apache-Test';
require 'install-pl' if APACHE_TEST_INSTALL;
}
to:
BEGIN {
use constant APACHE_TEST_INSTALL = -e 'Apache-Test';
I think this is the bit that isn't working. The constant isn't being
set, so the -e 'Apache-Test' test is failing.
This would be consistant with there being no such directory if you
do a straight CVS checkout, rather than untar'ing a distribution
and then using CVS updates. Is this something we need to fix in
the CVS tree, or something?
use lib './Apache-Test';
if (APACHE_TEST_INSTALL) {
warn loading install-pl';
require 'install-pl';
}
}
does it print loading install-pl?
no
Finally try replacing:
require 'install-pl';
with
require './install-pl';
Done, no change
Carl
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Useless use of a constant in void context at Makefile.PL line 467
Carl Brewer wrote:
[...]
Also what happens if you change
BEGIN {
use constant APACHE_TEST_INSTALL = -e 'Apache-Test';
use lib './Apache-Test';
require 'install-pl' if APACHE_TEST_INSTALL;
}
to:
BEGIN {
use constant APACHE_TEST_INSTALL = -e 'Apache-Test';
I think this is the bit that isn't working. The constant isn't being
set, so the -e 'Apache-Test' test is failing.
What do you mean by 'the constant not being set? It's either true or false,
bu it's always set. Does this work for you?
perl -lwe 'use constant A = -e Apache-Test1; print A ? OK : NOT OK;'
NOT OK
perl -lwe 'use constant A = -e Apache-Test; print A ? OK : NOT OK;'
OK
it's fine if Apache-Test is not there. APACHE_TEST_INSTALL should return false.
This would be consistant with there being no such directory if you
do a straight CVS checkout, rather than untar'ing a distribution
and then using CVS updates. Is this something we need to fix in
the CVS tree, or something?
Actually, it's not. If you do a fresh checkout, you get Apache-Test checked
out as well. Only if you remove it and do 'cvs up' it won't re-fetch that
directory.
But now that you told me the circumstances the problem happens at, I'm able to
reproduce it, after removing 'Apache-Test'. So I'll fix it ;)
__
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: Useless use of a constant in void context at Makefile.PL line 467
It's now fixed in cvs. Apparently constants don't seem to work when moved into a different namespace. May be a bug in perl, may be that's how it should be. In any case, moving to lexical variable solves the problem. __ 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]
[mp2] server coredump when using output filter with ModPerl::Registry
Hi list,
1. Problem Description:
I'm getting a variety of segfault conditions when I try to use an
output filter in conjunction with a ModPerl::Registry script. This is
highly repeatable; a freshly started httpd will segfault 3 times out
of 4.
If I turn off the output filter, the script runs just fine. If I run
the script under mod_cgi with the output filter enabled, it runs just
fine. Just fine = thousands of requests.
Also, if I use httpd -X, there are no segfaults with both
ModPerl::Registry and the output filter enabled. I have been unable
to get the server to generate a core file so far.
My error log contains entries as follows. These errors seem to occur
for each Apache prefork'd child except the initial process, and they
seem to appear at random, although the segfault errors appear 10-15
times as often as the others:
[Sun Oct 26 17:07:41 2003] [error] [client 192.168.1.1] Error reading
'/web/htdocs/gallery.cgi': 9:Bad file descriptor at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2/ModPerl/RegistryCooker.pm
line 528.
[Sun Oct 26 17:09:11 2003] [error] [client 192.168.1.1] Error: read 1 bytes,
expected 6333 ('/web/htdocs/gallery.cgi') at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2/ModPerl/RegistryCooker.pm
line 528.
[Sun Oct 26 17:15:32 2003] [error] [client 192.168.1.1] Error: read 1 bytes,
expected 6333 ('/web/htdocs/gallery.cgi') at
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2/ModPerl/RegistryCooker.pm
line 528.
[Sun Oct 26 17:15:44 2003] [notice] child pid 26289 exit signal Segmentation fault
(11)
[Sun Oct 26 17:16:07 2003] [notice] child pid 26290 exit signal Segmentation fault
(11)
[Sun Oct 26 17:16:13 2003] [notice] child pid 26287 exit signal Segmentation fault
(11)
My output filter uses Template Toolkit, and makes a connection to a
MySQL database, but is otherwise nothing special. It uses a handler
based very closely on the example in the mp2 docs (thanks Stas!).
2. Used Components and their Configuration:
RedHat Linux 9, kernel 2.4.20-20.9 on a Celeron 300A box with 256megs
of RAM, 512megs of swap (don't cringe), manually-built Apache and
modperl, as follows.
*** mod_perl version 1.9910
*** using lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX= /web/httpd
MP_COMPAT_1X= 1
MP_GENERATE_XS = 1
MP_INST_APACHE2 = 1
MP_LIBNAME = mod_perl
MP_USE_DSO = 1
MP_USE_STATIC = 1
*** /web/httpd/bin/httpd -V
Server version: Apache/2.0.47
Server built: Sep 21 2003 01:41:05
Server's Module Magic Number: 20020903:4
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR=server/mpm/prefork
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_PROC_PTHREAD_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=/web/httpd
-D SUEXEC_BIN=/web/httpd/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_LOCKFILE=logs/accept.lock
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.21-1.1931.2.382.entsmp, archname=i386-linux-thread-multi
uname='linux str'
config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686
-Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc.
-Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr
-Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm
-Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005
-Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef'
useithreads=define usemultiplicity=
useperlio= d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=un uselongdouble=
usemymalloc=, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/include/gdbm',
optimize='',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING
-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.2.2 20030222 (Red Hat Linux 3.2.2-5)', gccosandvers=''
gccversion='3.2.2 200302'
intsize=r, longsize=r, ptrsize=5, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long'
k', ivsize=4'
ivtype='l, nvtype='double'
Re: [mp2] server coredump when using output filter with ModPerl::Registry
Ewan Edwards wrote: [...] I have been unable to get a core dump. Evan, have you read: http://perl.apache.org/docs/2.0/devel/debug/c.html#Getting_the_core_File_Dumped We need the core stack and the code we can reproduce the problem with. Please reduce your code to the very minimal one that you still get the segfault with and send us the filter, the script and the relevant parts of the config. Thank you. __ 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: Useless use of a constant in void context at Makefile.PL line 467
Stas Bekman wrote: It's now fixed in cvs. Apparently constants don't seem to work when moved into a different namespace. May be a bug in perl, may be that's how it should be. In any case, moving to lexical variable solves the problem. Magic, thanks Stas :) Carl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
