Re: ModPerl::Registry: Software caused connection abort
Jeff Finn wrote:
Ok; I have generated a semi-self-contained Apache-test that will produce
this error.
This only happens on an SSL-enabled server
I was't able to get the alarm block working, but we can work around that
by starting the test, sleeping for a minute or so, and then in another
shell getting the url and ctrl-c'ing before the transfer completes.
in one shell
# make test TEST_VERBOSE=1
once the server starts, in another shell:
# curl -o /tmp/curl.out https://127.0.0.1:8530/handler
For some reason that doesn't work for me, I get:
curl -o /tmp/curl.out https://localhost:8530/handler
curl: (60) SSL certificate problem, verify that the CA cert is OK
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). The default
bundle is named curl-ca-bundle.crt; you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option.
If I use -k, and abort curl in the middle I get:
[Mon Aug 09 00:38:55 2004] [info] (32)Broken pipe: core_output_filter:
writing data to the network.
which is related, but not what you get. In my case I always get the core
output filter reports about the broken pipe.
The components I'm using:
[Mon Aug 09 00:44:01 2004] [notice] Apache/2.0.51-dev (Unix)
mod_perl/1.99_15-dev Perl/v5.8.5 mod_ssl/2.0.51-dev OpenSSL/0.9.7c DAV/2
configured -- resuming normal operations
Any difference if you eval $r->print in the response handler in the tar
ball you've supplied?
use APR::Error;
use APR::Const -compile => qw(ECONNABORTED);
...
foreach (1..(2**20)) {
eval { $r->print('01234567890abcdef') };
if ($@) {
if ($@ == APR::ECONNABORTED) {
# silently ignore client connection abort
}
else die $@;
}
}
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Using Cache::Mmap in mod_perl
On Tue, 20 Jul 2004 11:53:27 -0400, Perrin Harkins wrote: > On Tue, 2004-07-20 at 06:19, Victor Tsang wrote: > > Can't locate auto/Cache/Mmap/_lock.al in @INC > > You're having problems with autoloading. Check for the existence of > "auto/Cache/Mmap/_lock.al" on your system, and then check that its > path is in @INC when you run under mod_perl (command-line doesn't > count) and that the user you run mod_perl as can read it. I suspect > you will find a missing path or incorrect permissions somewhere. But the thing is, Cache::Mmap doesn't use autoloading. It inherits AutoLoader via DynaLoader (which is an ugly wart of DynaLoader's implementation, IMHO), but none of its own subs are supposed to be autoloaded. For Victor to be seeing the error he's getting, _lock() has either not been loaded, or it has been undefined after loading. However, read() and _bucket() have both managed to survive to that point in time. -- Peter Haworth [EMAIL PROTECTED] "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." -- [EMAIL PROTECTED] -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
ANNOUNCE: Krang 1.022
Krang v1.022 is now available. Notable changes in this release: - Category templates can now be published on a per-page basis, allowing for varying containers on each page of a story. - Improvements to the publishing system will result in greatly-improved sitewide publish times. - Krang::Story is now searchable by class. - Krang::Media is now searchable on a per-site basis - Additional minor bugfixes Detailed change-log here: http://krang.sf.net/docs/changelog.html Krang is an Open Source web-publisher / content-management system designed for large-scale magazine-style websites. It is a 100% Perl application using Apache/mod_perl and MySQL, as well as numerous CPAN modules. Krang provides a powerful and easy to use story and media editing environment for magazine editors, as well as a complete template development environment for web designers. On the back-end, Perl programmers can customize Krang to control the data entered in the story editor and add code to drive the templates to build output. Krang can be enhanced with add-ons containing new skins and other new features. Krang easily handles large data sets and can manage multiple websites in a single installation. For more information about Krang, visit the Krang website: http://krang.sourceforge.net/ There you can download Krang, view screenshots, read documentation, join our mailing-lists and access the CVS tree. - the Krang team -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: ModPerl::Registry: Software caused connection abort
From: "Jeff Finn" <[EMAIL PROTECTED]> Ok; I have generated a semi-self-contained Apache-test that will produce this error. I'm glad, because I wasn't having any luck producing a simple test case that would work from IE, much less something more reproducible! Hopefully now the mod_perl wizards can get to the bottom of the problem. -- Dan Wilga [EMAIL PROTECTED] Web Technology Specialist http://www.mtholyoke.edu Mount Holyoke CollegeTel: 413-538-3027 South Hadley, MA 01075"Who left the cake out in the rain?" -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: make test hangs
Apologies. You are correct. I never responded directly to this email. my $file = "/tmp"; my $mtime = (stat $file)[9]; and: my $file = __FILE__; my $mtime = (stat $file)[9]; both fail (meaning the test hangs) -M __FILE__; and -M "/tmp"; both work (which is to say that the test does not hang, but the test fails because stat returns number of seconds since the epoch and -M returns the number of days since last modification). Apache, perl and mod_perl where all compiled with HP's ANSI C compiler. The compiler is now with the latest version and patch level. Also, will point out that this is now under HP-UX 11i (11.11) was formerly HP-UX 11.00. Not sure this matters since the symptom's of the problem remain unchanged. When I first reported the problem I was on the eve of upgrading the OS on the server I've been trying to get this working on. --- Will Fulmer Database Administrator Northampton Community College Bethlehem, PA >>> Stas Bekman <[EMAIL PROTECTED]> 8/8/2004 10:43:14 PM >>> William, please followup on all the emails. I don't think I've seen your followup to this post: http://marc.theaimsgroup.com/?l=apache-modperl&m=108382020514594&w=2 Did I miss it? -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
RE: ModPerl::Registry: Software caused connection abort
Except Stas is not getting the error when he tries it... hmm. I'm going to check it again tonight, and I'll include the error log output. I'm also going to try to use the eval statement he suggested in the test, but I'm not sure that it will be practical for me in my application. BTW, Stas: certain versions of curl require -k to disable verification of the certificate... on cygwin it does, but on redhat 9.0 it doesn't. Sorry, I forgot to mention that in my reply Jeff -Original Message- From: Dan Wilga [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 11:53 AM To: [EMAIL PROTECTED] Subject: RE: ModPerl::Registry: Software caused connection abort >From: "Jeff Finn" <[EMAIL PROTECTED]> >Ok; I have generated a semi-self-contained Apache-test that will produce >this error. I'm glad, because I wasn't having any luck producing a simple test case that would work from IE, much less something more reproducible! Hopefully now the mod_perl wizards can get to the bottom of the problem. -- Dan Wilga [EMAIL PROTECTED] Web Technology Specialist http://www.mtholyoke.edu Mount Holyoke CollegeTel: 413-538-3027 South Hadley, MA 01075"Who left the cake out in the rain?" -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: make test hangs
William Fulmer wrote:
Apologies. You are correct. I never responded directly to this email.
my $file = "/tmp";
my $mtime = (stat $file)[9];
and:
my $file = __FILE__;
my $mtime = (stat $file)[9];
both fail (meaning the test hangs)
-M __FILE__;
and
-M "/tmp";
both work (which is to say that the test does not hang, but the test
fails because stat returns number of seconds since the epoch and -M
returns the number of days since last modification).
Right, but I think both perform stat(). I went back to your strace
message, which had:
write(2, "N o - M a l l o w e d w h ".., 36)
. = 36
with some googling I've found:
http://marc.theaimsgroup.com/?l=apache-modperl&m=104941790431878&w=2
which is talking about:
"waiting for server to start: .No -M allowed while running setuid.
perl_parse: Address family not supported by protocol
!!!
server has died with status 1 (please examine t/logs/error_log)
make: *** [run_tests] Error 143 "
Could that be your issue? Do you have setuid involved in your setup?
If you build mod_perl as root as Richard mentioned in the above URL, do
you get any difference?
the error is coming from perl.c:
STATIC void
S_forbid_setid(pTHX_ char *s)
{
#ifdef SETUID_SCRIPTS_ARE_SECURE_NOW
if (PL_euid != PL_uid)
Perl_croak(aTHX_ "No %s allowed while running setuid", s);
if (PL_egid != PL_gid)
Perl_croak(aTHX_ "No %s allowed while running setgid", s);
#endif /* SETUID_SCRIPTS_ARE_SECURE_NOW */
/* PSz 29 Feb 04
* Checks for UID/GID above "wrong": why disallow
* perl -e 'print "Hello\n"'
* from within setuid things?? Simply drop them: replaced by
* fdscript/suidscript and #ifdef IAMSUID checks below.
*
* This may be too late for command-line switches. Will catch those on
* the #! line, after finding the script name and setting up
* fdscript/suidscript. Note that suidperl does not get around to
* parsing (and checking) the switches on the #! line, but checks that
* the two sets are identical.
*
* With SETUID_SCRIPTS_ARE_SECURE_NOW, could we use fdscript, also or
* instead, or would that be "too late"? (We never have suidscript, can
* we be sure to have fdscript?)
*
* Catch things with suidscript (in descendant of suidperl), even with
* right UID/GID. Was already checked in suidperl, with #ifdef IAMSUID,
* below; but I am paranoid.
*
* Also see comments about root running a setuid script, elsewhere.
*/
Apache, perl and mod_perl where all compiled with HP's ANSI C compiler.
The compiler is now with the latest version and patch level. Also,
will point out that this is now under HP-UX 11i (11.11) was formerly
HP-UX 11.00. Not sure this matters since the symptom's of the problem
remain unchanged. When I first reported the problem I was on the eve of
upgrading the OS on the server I've been trying to get this working on.
That's good.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: ModPerl::Registry: Software caused connection abort
Jeff Finn wrote: Except Stas is not getting the error when he tries it... hmm. I'm going to check it again tonight, and I'll include the error log output. I'm also going to try to use the eval statement he suggested in the test, but I'm not sure that it will be practical for me in my application. Please try it to see whether it works. Until I manage to reproduce it myself, I can only guess what could possible work. It's strange why it doesn't work with LWP. I think one needs to look how Apache::Test deals with ssl, since it does have support for it. BTW, Stas: certain versions of curl require -k to disable verification of the certificate... on cygwin it does, but on redhat 9.0 it doesn't. Sorry, I forgot to mention that in my reply Thanks Jeff, I read the manpage :) -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Unintal v.1, install v.2 question
On a Linux system, I am having trouble uninstalling Mod Perl 1.29 during my install of Mod Perl 2 [EMAIL PROTECTED] mod_perl-1.99_14]# perl Makefile.PL APACHE_SRC =../httpd-2.0.50/src \ > DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 Reading Makefile.PL args from @ARGV mod_perl/1.29 installation detected...[ error] not ok [ error] cannot install mod_perl/1.99_14 on top of mod_perl/1.29 [ error] use MP_INST_APACHE2=1 option or to force installation delete: /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/mod_perl.pm I checked the path to the mod_perl.pm and the file is not there. How do I uninstall 1.29 so that I can have only version 2? Brian Hall Webmaster Eagle-Tribune Publishing Company -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Unintal v.1, install v.2 question
[EMAIL PROTECTED] wrote: On a Linux system, I am having trouble uninstalling Mod Perl 1.29 during my install of Mod Perl 2 [EMAIL PROTECTED] mod_perl-1.99_14]# perl Makefile.PL APACHE_SRC =../httpd-2.0.50/src \ DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 Reading Makefile.PL args from @ARGV mod_perl/1.29 installation detected...[ error] not ok [ error] cannot install mod_perl/1.99_14 on top of mod_perl/1.29 [ error] use MP_INST_APACHE2=1 option or to force installation delete: /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/mod_perl.pm I checked the path to the mod_perl.pm and the file is not there. How do I uninstall 1.29 so that I can have only version 2? Something like: find /usr/lib/perl5/ | grep mod_perl | xargs rm -rf find /usr/lib/perl5/ | grep Apache | xargs rm -rf note that it'll nuke any other Apache modules, but it's probably a good thing. You probably also have /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi/auto/mod_perl/.packlist which you could feed to rm. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Date parsing (was Re: [mp2 milestones] installment 1)
On Friday 28 May 2004 01:36 pm, Stas Bekman wrote: > >>http://perl.apache.org/docs/2.0/api/APR/Date.html > > Are these parsers any faster than the perl module ones? (Ie. any reason > > for using these over Date::Time or similar?) > > They are written in C, so if Date::Time is not, APR::Date is probably > faster. But don't take my word for granted as I didn't benchmark -- run > Benchmark.pm and post your findings to the list for the rest to know. > Thanks! I finally got chance to do this, here's the results from parsing 'Sun, 06 Nov 1994 08:49:37 GMT', with 1 iterations using Benchmark::timethis. There's actually quite a number of different date parsing modules on cpan, each of which does something slightly different. Date::Parse::str2time 3 wallclock secs ( 3.58 usr + 0.01 sys = 3.59 CPU) @ 2785.52/s Time::ParseDate::parsedate 4 wallclock secs ( 3.35 usr + 0.01 sys = 3.36 CPU) @ 2976.19/s Date::Manip::ParseDate 63 wallclock secs (63.12 usr 0.02 sys + 0.01 cusr 0.01 csys = 63.16 CPU) @ 158.38/s APR::Date::parse_rfc: 0 wallclock secs ( 0.04 usr + 0.00 sys = 0.04 CPU) @ 25.00/s APR::Date::parse_http: 0 wallclock secs ( 0.03 usr + 0.00 sys = 0.03 CPU) @ 33.33/s So, assuming the date you have is either HTTP-compliant or RFC822-compliant, then the APR::Date functions are orders of magnitude faster. Hopefully this is of use to someone. -- There's only one corner of the universe you can be certain of improving, and that's your own self. - Aldous Huxley -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Date parsing (was Re: [mp2 milestones] installment 1)
On Mon, 2004-08-09 at 18:31, MJH wrote: > So, assuming the date you have is either HTTP-compliant or RFC822-compliant, > then the APR::Date functions are orders of magnitude faster. > > Hopefully this is of use to someone. It is, thanks. APR::Base64 and APR::URI look pretty useful too. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Date parsing (was Re: [mp2 milestones] installment 1)
MJH wrote: On Friday 28 May 2004 01:36 pm, Stas Bekman wrote: http://perl.apache.org/docs/2.0/api/APR/Date.html Are these parsers any faster than the perl module ones? (Ie. any reason for using these over Date::Time or similar?) They are written in C, so if Date::Time is not, APR::Date is probably faster. But don't take my word for granted as I didn't benchmark -- run Benchmark.pm and post your findings to the list for the rest to know. Thanks! I finally got chance to do this, here's the results from parsing 'Sun, 06 Nov 1994 08:49:37 GMT', with 1 iterations using Benchmark::timethis. There's actually quite a number of different date parsing modules on cpan, each of which does something slightly different. Would you be willing to add other modules to your benchmark? I would be interested to see how HTTP::Date and DateTime::Format::HTTP (which uses HTTP::Date) compare. Thanks, Stuart Johnston -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] registry tests problems (powerpc-aix-5.1.0.0 platform / IBM RS6000)
I think I may know what the problem is (at least one of them). I've used
that t/cgi.t test with ModPerl-Registry and stepped through with gdb on
your machine.
This particular problem of not having Apache->request available, even
though you run under 'SetHandler perl-script' seems to be due to the use
of static variables.
src/modules/perl/modperl_global.c creates a static variable for $r.
static modperl_global_t MP_tls_##gname;
which after expanding macros translates to:
static modperl_global_t *MP_tls_request_rec
Now observe:
Breakpoint 7, modperl_global_request_set (r=0x20e3d738) at
modperl_global.c:31
31 MP_dRCFG;
(gdb) n
...
(gdb) n
38 modperl_tls_set_request_rec(r);
(gdb) p *MP_tls_request_rec
$28 = {flags = 0, data = 0x0, name = 0x0}
That's the value of MP_tls_request_rec before setting it to $r
(gdb) n
41 MpReqSET_GLOBAL_REQUEST_On(rcfg);
(gdb) p *MP_tls_request_rec
$29 = {flags = 0, data = 0x0, name = 0x0}
As you can see it ain't working. So obviously when later on it tries to
get that data out and use it, it fails and hence you get this kind of
errors:
Global $r object is not available. Set:\n\tPerlOptions
+GlobalRequest\nin httpd.conf at ...
So, are you aware with problems of using static variables on your
platform? Is it compiler specific? Does it get them optimized away or
something?
If you rebuild your perl with ithreads and APR has ithreads too, which
seems to be the case, since it links pthread
*** (apr|apu)-config linking info
-L/usr/local/apache2/lib -lapr-0 -lm -lnsl -lpthread
-L/usr/local/apache2/lib -laprutil-0 -ldb-4.2 -lexpat -liconv
and then rebuild mod_perl, it may fare better, as it'll use TLS instead
of the static for this particular thing. If your threads implementation
is good it should work well.
Another possibility to try is to compile mod_perl statically, but I'm
not sure if it's going to make any difference. I'd try a threaded perl
first.
BTW, should you explore it on your own (and may be faster machine :)
I've attached the gdb debug script I have used. You use it as follows:
console one: gdb --command=debug
wait a bit now:
console two: t/TEST -v -run t/cgi.t
For more information see:
http://perl.apache.org/docs/2.0/devel/debug/c.html#Precooked_gdb_Startup_Scripts
--
__
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
# This gdb startup script breaks at the mpxs_Apache__Filter_print()
# function from the XS code, as an example how you can debug the code
# in XS extensions.
#
# Invoke as:
# gdb -command=.debug-modperl-xs
# and then run:
# t/TEST -v -run -ping=block filter/api
#
# see ADJUST notes for things that may need to be adjusted
# ADJUST: the path to the httpd executable if needed
file /usr/local/apache2/bin/httpd
handle SIGPIPE nostop
handle SIGPIPE pass
set auto-solib-add 0
define myrun
tbreak main
break ap_run_pre_config
dir /u0/stas/modperl-2.0/src/modules/perl
# ADJUST: the httpd.conf file's path if needed
# ADJUST: add -DPERL_USEITHREADS to debug threaded mpms
run -d `pwd`/t -f `pwd`/t/conf/httpd.conf \
-DONE_PROCESS -DNO_DETATCH -DAPACHE2
continue
end
define sharedap
sharedlibrary apr
sharedlibrary aprutil
#sharedlibrary mod_ssl.so
continue
end
define sharedperl
sharedlibrary libperl
end
define gopoll
b apr_poll
continue
#continue
end
define mybp
sharedlibrary mod_perl.so
#sharedlibrary Apache/RequestIO
sharedlibrary RequestUtil.so
b modperl_response_handler_cgi
b modperl_global_request_set
b modperl_global_request
b modperl_tls_create
# no longer needed and they just make debugging harder under threads
disable 2
disable 3
continue
end
myrun
gopoll
# ADJUST: uncomment if you need to step through the code in apr libs
sharedap
# ADJUST: uncomment if you need to step through the code in perlib
sharedperl
mybp
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Multiple Aliases in Perl Section name virtual hosts
Philippe M. Chiasson wrote:
>> Does the following patch solve the problem for you ?
>
> ? make.log
> Index: lib/Apache/PerlSections.pm
> ===
> RCS file: /home/cvs/modperl-2.0/lib/Apache/PerlSections.pm,v
> retrieving revision 1.5
> diff -u -I$Id -r1.5 PerlSections.pm
> --- lib/Apache/PerlSections.pm9 Jul 2004 08:01:20 - 1.5
> +++ lib/Apache/PerlSections.pm6 Aug 2004 22:30:01 -
> @@ -172,7 +172,12 @@
> $self->add_config("$name $$entry\n");
> }
> elsif ($type eq 'ARRAY') {
> -$self->add_config("$name @$entry\n");
> +if (grep { ref($_) } @$entry) {
> +$self->dump_entry($name, $_) for @$entry;
> +}
> +else {
> +$self->add_config("$name @$entry\n");
> +}
> }
> elsif ($type eq 'HASH') {
> $self->dump_hash($name, $entry);
>
Philippe, I applied the patch you included in your earlier posting. It fixed the
problem for me.
Thanks for your help.
--Kim
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [mp2] registry tests problems (powerpc-aix-5.1.0.0 platform / IBM RS6000)
I guess I am slowly starting to understand what's happening. I've built
modperl on other machine which has perl with ithreads, at least perl -V
produces:
[quote]
osname=aix, osvers=5.1.0.0, archname=aix-thread-multi
config_args=''
hint=previous, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
[unquote]
APR/APU config hast -lpthreads in it, and modperl Makefile has
-lpthreads and _THREAD_SAFE macro defined.
The result of t/cgi.t test is exactly the same as you described,
error_log shows:
[error] Global $r object is not available. Set:\n\tPerlOptions +GlobalRequest\nin
httpd.conf at /usr/local/li
b/perl5/5.8.5/CGI.pm line 315.\n
There must be something wrong with static variables then, threads
implementation on this platform is good enough to my belief for major
software like Oracle, Apache or perl. We seem to be fairly close to
positive result, I guess. I'll try to investigate, make
some tests and revert back to you as soon as there are any results.
Regards
Alexei
[skipped]
SB> (gdb) n
SB> 41 MpReqSET_GLOBAL_REQUEST_On(rcfg);
SB> (gdb) p *MP_tls_request_rec
SB> $29 = {flags = 0, data = 0x0, name = 0x0}
SB> As you can see it ain't working. So obviously when later on it tries to
SB> get that data out and use it, it fails and hence you get this kind of
SB> errors:
SB> Global $r object is not available. Set:\n\tPerlOptions
SB> +GlobalRequest\nin httpd.conf at ...
SB> So, are you aware with problems of using static variables on your
SB> platform? Is it compiler specific? Does it get them optimized away or
SB> something?
SB> If you rebuild your perl with ithreads and APR has ithreads too, which
SB> seems to be the case, since it links pthread
[skipped]
** Mother Nature is a bitch.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
