modperl 1.99_1, Apache 2.0.50 - make test failure
Hi, I'm new to this list and trying to compile modperl for Apache2. (I've done this some time ago for modperl 1.26 and Apache 1.3.22.) I'm using Perl 5.8.5 under AIX 4.3.3. My compiler is vac 5.0.2.8. Everything compiles well and Apache2 is running wonderful on it's own. I've done the following for modperl: $ perl Makefile.PL MP_APXS=/www/apache2/bin/apxs MP_USE_DSO=1 MP_INST_APACHE2=1 $ make $ make test And here is the first error: make test produces this output at the end: ==cut here == usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /build/perl/mod_perl-1.99_16/t/TEST -clean APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -bugreport -verbose=0 [warning] setting ulimit to allow core files ulimit -c unlimited; /usr/bin/perl /build/perl/mod_perl-1.99_16/t/TEST -bugreport -verbose=0 /www/apache2/bin/httpd -d /build/perl/mod_perl-1.99_16/t -f /build/perl/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 using Apache/2.0.50 (prefork MPM) waiting 120 seconds for server to start: ..[Wed Sep 08 10:50:44 2004] [info] 26 Apache:: modules loaded [Wed Sep 08 10:50:44 2004] [info] 7 APR:: modules loaded [Wed Sep 08 10:50:44 2004] [info] base server + 20 vhosts ready to run tests waiting 120 seconds for server to start: not ok [ error] giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. by setting the environment variable APACHE_TEST_STARTUP_TIMEOUT to a high value (e.g. 420) and repeat the last command. [ error] server failed to start! (please examine t/logs/error_log) ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ make: *** [run_tests] Error 1 ==cut here == And in the error_log is only one line: END in modperl_extra.pl, pid=19306 What shall I do now? Does anyone have the same problem? I've tried to run the command with strace, but I think this works different under AIX, because it won't start, when I say: strace /www/apache2/bin/httpd -d /build/perl/mod_perl-1.99_16/t -f /build/perl/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -DONE_PROCESS -DNO_DETATCH It complains: usage: strace [mid sid level] ... I've never done anything with strace so far. Is there anybody out there who can help me? TIA, best regards, Johannes == Johannes Grumböck Porsche Informatik GmbH Handelszentrum 7 A-5101 Bergheim Tel.: +43 662 4670 6323 Fax: +43 662 4670 16323 -- 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
Antwort: Re: modperl 1.99_1, Apache 2.0.50 - make test failure
Hi, I've managed something new: make test ist running after deactivating every LoadModule in /www/apache2/httpd.conf from which make test generates it's own httpd.conf. Now the tests are running. So it seems to be a problem with the LoadModule-order. The following modules are built into httpd: Compiled in modules: core.c mod_access.c mod_auth.c mod_include.c mod_deflate.c mod_log_config.c mod_env.c mod_setenvif.c prefork.c http_core.c mod_mime.c mod_status.c mod_autoindex.c mod_asis.c mod_cgi.c mod_negotiation.c mod_dir.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_so.c And the follwing modules should be included (but are commented out now): #LoadModule auth_dbm_module modules/mod_auth_dbm.so #LoadModule proxy_module modules/mod_proxy.so #LoadModule proxy_connect_module modules/mod_proxy_connect.so #LoadModule proxy_ftp_module modules/mod_proxy_ftp.so #LoadModule proxy_http_module modules/mod_proxy_http.so IfDefine SSL #LoadModule ssl_module modules/mod_ssl.so /IfDefine #LoadModule dav_module modules/mod_dav.so #LoadModule info_module modules/mod_info.so #LoadModule dav_fs_module modules/mod_dav_fs.so #LoadModule rewrite_module modules/mod_rewrite.so I'll try to activate one after another to see found out which one's the bad guy. best regards, Johannes Alexey Bozrikov [EMAIL PROTECTED] schrieb am 08.09.2004 11:54:12: Yep, having the same on AIX 5.1L, VAC/C++ 6.0. Stas managed to track it down to some static variables being optimised away or something in mod_perl ($r object out of scope), I've got no idea where to go from here. I could supply you with all debugging information I've got about it if you're keen on debugging it... regards Alexey jgpca Hi, jgpca I'm new to this list and trying to compile modperl for Apache2. jgpca (I've done this some time ago for modperl 1.26 and Apache 1.3.22.) jgpca I'm using Perl 5.8.5 under AIX 4.3.3. My compiler is vac 5.0.2.8. jgpca Everything compiles well and Apache2 is running wonderful on it's own. jgpca I've done the following for modperl: $ perl Makefile.PL MP_APXS=/www/apache2/bin/apxs MP_USE_DSO=1 jgpca MP_INST_APACHE2=1 $ make $ make test jgpca And here is the first error: jgpca make test produces this output at the end: jgpca ==cut here jgpca == jgpca usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ jgpca t/TEST -clean jgpca [warning] setting ulimit to allow core files jgpca ulimit -c unlimited; /usr/bin/perl jgpca /build/perl/mod_perl-1.99_16/t/TEST jgpca -clean jgpca APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= jgpca APACHE_TEST_APXS= \ jgpca /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ jgpca t/TEST -bugreport -verbose=0 jgpca [warning] setting ulimit to allow core files jgpca ulimit -c unlimited; /usr/bin/perl jgpca /build/perl/mod_perl-1.99_16/t/TEST jgpca -bugreport -verbose=0 jgpca /www/apache2/bin/httpd -d /build/perl/mod_perl-1.99_16/t -f jgpca /build/perl/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 jgpca using Apache/2.0.50 (prefork MPM) jgpca waiting 120 seconds for server to start: ..[Wed Sep 08 10:50:44 2004] jgpca [info] 26 Apache:: modules loaded jgpca [Wed Sep 08 10:50:44 2004] [info] 7 APR:: modules loaded jgpca [Wed Sep 08 10:50:44 2004] [info] base server + 20 vhosts ready to run jgpca tests jgpca jgpca waiting 120 seconds for server to start: not ok jgpca [ error] giving up after 121 secs. If you think that your system jgpca is slow or overloaded try again with a longer timeout value. jgpca by setting the environment variable APACHE_TEST_STARTUP_TIMEOUT jgpca to a high value (e.g. 420) and repeat the last command. jgpca [ error] server failed to start! (please examine t/logs/error_log) jgpca ++ jgpca | Please file a bug report: http://perl.apache.org/bugs/ | jgpca ++ jgpca make: *** [run_tests] Error 1 jgpca ==cut here jgpca == jgpca And in the error_log is only one line: jgpca END in modperl_extra.pl, pid=19306 jgpca What shall I do now? jgpca Does anyone have the same problem? jgpca I've tried to run the command with strace, but I think this works different jgpca under AIX, jgpca because it won't start, when I say: jgpca strace /www/apache2/bin/httpd -d jgpca /build/perl/mod_perl-1.99_16/t -f jgpca /build/perl/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -DONE_PROCESS jgpca -DNO_DETATCH jgpca It complains: usage: strace [mid sid level] ... jgpca I've never done anything with strace so far. jgpca Is
Re: perl modules not running after 'minor' change
Geoffrey Young wrote: Geoffrey Young wrote: That sounds like a job for Apache to do. Apache knows what modules are compiled in, so it can check that list before trying to LoadModule. You may want to suggest that to the Apache developers. Most likely any Apache module suffers from this problem. ok, as it turns out this logic is already part of 2.0, but it was never backported to 1.3. attached is a patch that I've submitted to httpd-dev, which is simply a pure backport of the existing logic in 2.0. feel free to give it a whirl. this has been applied to the Apache 1.3 tree and will be part of the 1.3.32 release. thanks all! --Geoff -- 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: PerlTransHandler, Location
eps com estem wrote: Hi. I want to redirect to some uri one page. This can be accomplished easily in PerlTransHandler with $r- uri($new_uri); My problem is that this uri needs to be parsed again with the same module responsible of that. This is, i have a web page parse by module X that has to redirect to another uri that has to pass again by module X at the same PerlTransHandler phase. So $r- uri($new_uri); does not work because the new uri goes on after the PerlTransHandler phase, and it's not valid for me. None of this options has worked. What i am doing wrong? What i use in the past was a rude javascript printed in the web page that redirected automatically to the url. Now i want to use the modperl api to do it. I'm afraid I don't fully understand what you are trying to do, but it sounds as though $r-internal_redirect() is what you are after - it essentially mimics a browser redirect, placing the new request through the entire request cycle (including the PerlTransHandler) but without telling the browser about it. HTH --Geoff -- 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
[mp2] Setting correct charset / content encoding for request
Hello! Let me get the system specs out of the way first... Apache: 2.0.50 mod_perl: 1.99_16 Apreq2: 2.04-dev Perl: 5.8.5 I am attempting to set the charset value in the response headers to 'utf8', but I can't seem to get it to drop the 'iso-8859-1' value for some reason. I began with the following code: (Assuming $ContentType = text/html) $r-content_type($ContentType; charset=utf-8); $r-print($Request); And the response headers look like this: Date: Wed, 08 Sep 2004 15:29:56 GMT Server: Apache/2.0.50 (Unix) mod_perl/1.99_16 Perl/v5.8.5 Content-Type: text/html; charset=ISO-8859-1 Then I changed the code to use the content_encoding function: $r-content_type($ContentType); #($ContentType; charset=utf-8); $r-content_encoding(utf8); $r-print($Request); And now the response headers look like this: Date: Wed, 08 Sep 2004 15:33:21 GMT Server: Apache/2.0.50 (Unix) mod_perl/1.99_16 Perl/v5.8.5 Content-Type: text/html; charset=ISO-8859-1 Content-Encoding: utf8 For some reason, I cannot get the Content-Type: string to just be text/html or text/html; charset=utf8. I have a feeling that Content-Encoding has nothing to do with what I am trying to achieve here Am I missing something completely obvious here? Any help would be appreciated. Thanks, Chris Jacobson -- 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: mod_perl sometimes prints to error log instead of client
On Mon, 2004-09-06 at 23:15, Ryan Underwood wrote:
I've had this strange problem off and on ever since we started using
mod_perl. Occasionally, when the page is generated and printed, the
output goes to the Apache error log instead of to the client
[...]
PerlHeaderParserHandler sub { tie *STDOUT, 'Apache' unless tied *STDOUT;
}
I suspect either the above hack, or Apache::DynaGzip and
Apache::RegistryFilter. These are messing with where your STDOUT gets
sent and could lead to strange results if something died part-way
through.
- 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: mod_perl sometimes prints to error log instead of client
Sorry guys, I missed the beginning of this thread, won't you mind to
remind me what is Apache::Dynagzip suspected in?
Slava
On Wed, 2004-09-08 at 13:19, Perrin Harkins wrote:
On Mon, 2004-09-06 at 23:15, Ryan Underwood wrote:
I've had this strange problem off and on ever since we started using
mod_perl. Occasionally, when the page is generated and printed, the
output goes to the Apache error log instead of to the client
[...]
PerlHeaderParserHandler sub { tie *STDOUT, 'Apache' unless tied
*STDOUT; }
I suspect either the above hack, or Apache::DynaGzip and
Apache::RegistryFilter. These are messing with where your STDOUT gets
sent and could lead to strange results if something died part-way
through.
- 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: [mp2] coredump in t/filter/in_error on Solaris 8
Stas Bekman wrote:
Arshavir Grigorian wrote:
Stas Bekman wrote:
Arshavir Grigorian wrote:
-8-- Start Bug Report 8--
1. Problem Description:
make test fails on one of the tests -
t/filter/in_error...malformed response at
/usr/local/apache2/build/mod_perl-1.99_16/blib/lib/Apache/TestClient.pm
line 102.
t/filter/in_error...NOK 1# Failed test 1 in
t/filter/in_error.t at line 13
t/filter/in_error...FAILED test 1 Failed 1/1
tests, 0.00% okay
Arshavir, your report lacks the error_log part, please check again:
http://perl.apache.org/docs/2.0/user/help/help.html#_C_make_test___Failures
(gdb) bt
#0 apr_cpystrn (dst=0xffbef010 , src=0x0, dst_size=4290703375)
at apr_cpystrn.c:57
#1 0xff1d4c4c in stuffbuffer (buf=0xffbeef10 , bufsize=256, s=0x0)
at errorcodes.c:34
#2 0xfee074f0 in modperl_error_strerror (rc=500) at
modperl_error.c:37
#3 0xfe990c90 in XS_APR__Error_strerror (cv=0x1f4) at Error.xs:36
It looks like a bug in apr, and not modperl. But for some reason the
backtrace missing frame (may be they were optimized away). could you
possibly break at apr_strerror and see which of the following
branches it took before reaching apr_cpystrn()?
errorcodes.c:
APR_DECLARE(char *) apr_strerror(apr_status_t statcode, char *buf,
apr_size_t bufsize)
{
if (statcode APR_OS_START_ERROR) {
return native_strerror(statcode, buf, bufsize);
}
else if (statcode APR_OS_START_USERERR) {
return stuffbuffer(buf, bufsize, apr_error_string(statcode));
}
else if (statcode APR_OS_START_EAIERR) {
return stuffbuffer(buf, bufsize, APR does not understand this error
code);
}
else if (statcode APR_OS_START_SYSERR) {
#if defined(HAVE_GAI_STRERROR)
statcode -= APR_OS_START_EAIERR;
#if defined(NEGATIVE_EAI)
statcode = -statcode;
#endif
return stuffbuffer(buf, bufsize, gai_strerror(statcode));
#else
return stuffbuffer(buf, bufsize, APR does not understand this error
code);
#endif
}
else {
return apr_os_strerror(buf, bufsize, statcode - APR_OS_START_SYSERR);
}
}
On a different note, for some very odd reason, sometimes the httpd
process does not start for testing and other times it does.
I have tried the compilation several times with exact same
parameters, and I still cannot pinpoint a reason why that happens.
Could this be the reason?
http://perl.apache.org/docs/2.0/user/troubleshooting/troubleshooting.html#Server_Hanging_at_the_Startup
Thanks for the reply.
I looked at the error_log and there is a comment that the errors
causing the core dump are harmless.
Yes, the error is harmless, since that test is testing exactly that:
how modperl handles errors. It must not dump a core of course.
*** The following 2 error entries are expected and harmless ***
[Tue Sep 07 15:23:39 2004] [error] [client 127.0.0.1] This filter
must die at /u
sr/local/apache2/build/mod_perl-1.99_16/t/filter/TestFilter/in_error.pm
line 26.
\n
This filter must die at
/usr/local/apache2/build/mod_perl-1.99_16/t/filter/TestF
ilter/in_error.pm line 26.
So I am wondering why the test is failing even though it's expecting
an HTTP 500 response. I am also wondering whether the warn call at
/usr/local/apache2/build/mod_perl-1.99_16/blib/lib/Apache/TestClient.pm
line 102 has anything to do with it since all the warnings are
configured to be fatal.
No, it fails because of the coredump. Apache didn't send any response
when it segfaulted, not even 500 response.
I'd appreciate if you could work with the debugger and figure out the
real trace it has taken to help us debug it, as suggested in the
previous reply.
It looks like the control is going into the first branch of the if
statement calling native_strerror (statcode=500, buf=0xffbeef10 ,
bufsize=256).
Here is a new backtrace:
#0 0xff2a7fec in apr_cpystrn (dst=0xffbeee90 \001, src=0x0, dst_size=256)
at apr_cpystrn.c:57
57 if (!(*d = *src)) {
(gdb) where
#0 0xff2a7fec in apr_cpystrn (dst=0xffbeee90 \001, src=0x0, dst_size=256)
at apr_cpystrn.c:57
#1 0xff2c0f18 in stuffbuffer (buf=0xffbeee90 \001, bufsize=256, s=0x0)
at errorcodes.c:34
#2 0xff2c18e8 in native_strerror (statcode=-4264304,
buf=0x100 Address 0x100 out of bounds, bufsize=0) at errorcodes.c:375
(gdb)
Hope that's useful.
Arshavir
--
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: mod_perl sometimes prints to error log instead of client
On Wed, Sep 08, 2004 at 02:19:17PM -0400, Perrin Harkins wrote:
On Mon, 2004-09-06 at 23:15, Ryan Underwood wrote:
I've had this strange problem off and on ever since we started using
mod_perl. Occasionally, when the page is generated and printed, the
output goes to the Apache error log instead of to the client
[...]
PerlHeaderParserHandler sub { tie *STDOUT, 'Apache' unless tied
*STDOUT; }
I suspect either the above hack, or Apache::DynaGzip and
Apache::RegistryFilter. These are messing with where your STDOUT gets
sent and could lead to strange results if something died part-way
through.
Well, I know it did it before installing DynaGzip, and the above hack
according to the URL above it in the original mail was put in there to
address the same issue. I wasn't aware RegistryFilter could be an
issue, so I'll look into that.
When you say something died part-way through, do you mean the Apache
process, a Perl script dying, or what?
--
Ryan Underwood, [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
Re: mod_perl sometimes prints to error log instead of client
On Wed, 2004-09-08 at 14:48, Perrin Harkins wrote: Archived here: http://mathforum.org/epigone/modperl/swoxsnurcro/[EMAIL PROTECTED] Apache::Dynagzip is commented out in questioning configuration. This is right first step to do in the first place when you suspect any incompatibility. However, it is not quite clear from the message, whether the problem disappears after commenting Apache::Dynagzip or not? Thanks, Slava -- 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
Antwort: Re: modperl 1.99_1, Apache 2.0.50 - make test failure
Hi Stas, I tried the Timeout-value and as you thought it hasn't any influence because with the prefork-model the server needs around 26secs to startup. I found something new. As I commented out every module I tried to figure out which one is the bad one, so I activated one after the other and did t/TEST -conf and t/TEST each time. There are two bad ones. Each time I activated mod_proxy (ie. mod_proxy and mod_proxy_http) or mod_dav (ie. mod_dav and mod_dav_fs) the server didn't startup and quit silently. Independent of the fact which of the two modules I loaded and independent from the order of the Loadmodule-Statements. No chance in combination with mod_perl. So I compiled mod_proxy and mod_dav statically into httpd. And big surprise: Now everything works! :-) I got some errors (Can't load module...) on the test-routines for the APR:: modules. Should I post them here, because I don't know if this is a bug? Tomorrow I will try to do the strace thing for the case everyhting as DSO and then open a bug-report. kind regards, Johannes Stas Bekman [EMAIL PROTECTED] wrote on 08.09.2004 17:09:41: [EMAIL PROTECTED] wrote: I'm new to this list and trying to compile modperl for Apache2. (I've done this some time ago for modperl 1.26 and Apache 1.3.22.) I'm using Perl 5.8.5 under AIX 4.3.3. My compiler is vac 5.0.2.8. Johannes, to submit problem report please use: http://perl.apache.org/bugs/ waiting 120 seconds for server to start: not ok [ error] giving up after 121 secs. If you think that your system is slow or overloaded try again with a longer timeout value. by setting the environment variable APACHE_TEST_STARTUP_TIMEOUT to a high value (e.g. 420) and repeat the last command. [ error] server failed to start! (please examine t/logs/error_log) ++ | Please file a bug report: http://perl.apache.org/bugs/ | Have you read the suggestion? Did you try to set the startup timeout to a higher value? Though it's probably not the cause, especially not with prefork mpm, it's still something to try. And in the error_log is only one line: END in modperl_extra.pl, pid=19306 What shall I do now? Does anyone have the same problem? I've tried to run the command with strace, but I think this works different under AIX, because it won't start, when I say: strace /www/apache2/bin/httpd -d /build/perl/mod_perl-1.99_16/t -f /build/perl/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 -DONE_PROCESS -DNO_DETATCH It complains: usage: strace [mid sid level] ... I've never done anything with strace so far. Is there anybody out there who can help me? % man strace -- __ 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 -- 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: mod_perl sometimes prints to error log instead of client
On Wed, Sep 08, 2004 at 03:41:25PM -0500, Slava Bizyayev wrote: On Wed, 2004-09-08 at 14:48, Perrin Harkins wrote: Archived here: http://mathforum.org/epigone/modperl/swoxsnurcro/[EMAIL PROTECTED] Apache::Dynagzip is commented out in questioning configuration. This is right first step to do in the first place when you suspect any incompatibility. However, it is not quite clear from the message, whether the problem disappears after commenting Apache::Dynagzip or not? No, the problem doesn't go away without Dynagzip. I couldn't get Dynagzip to work correctly with a nph CGI script either. There is an option UseCGIHeadersFromScript but it appears to have no effect in the code. So I scrapped its usage for the time being. -- Ryan Underwood, [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
Re: [mp2] coredump in t/filter/in_error on Solaris 8
Arshavir Grigorian wrote:
I'd appreciate if you could work with the debugger and figure out the
real trace it has taken to help us debug it, as suggested in the
previous reply.
It looks like the control is going into the first branch of the if
statement calling native_strerror (statcode=500, buf=0xffbeef10 ,
bufsize=256).
Here is a new backtrace:
#0 0xff2a7fec in apr_cpystrn (dst=0xffbeee90 \001, src=0x0,
dst_size=256)
at apr_cpystrn.c:57
57 if (!(*d = *src)) {
(gdb) where
#0 0xff2a7fec in apr_cpystrn (dst=0xffbeee90 \001, src=0x0,
dst_size=256)
at apr_cpystrn.c:57
#1 0xff2c0f18 in stuffbuffer (buf=0xffbeee90 \001, bufsize=256, s=0x0)
at errorcodes.c:34
#2 0xff2c18e8 in native_strerror (statcode=-4264304,
buf=0x100 Address 0x100 out of bounds, bufsize=0) at errorcodes.c:375
(gdb)
Hope that's useful.
Well, this seems to be a totally different trace. What I was asking is to
work interactively with the gdb debugger and see where it goes wrong. I've
submitted your traces to the apr-dev list. Hopefully someone will know
what's going on.
--
__
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: mod_perl sometimes prints to error log instead of client
Hi Ryan, On Wed, 2004-09-08 at 15:56, Ryan Underwood wrote: No, the problem doesn't go away without Dynagzip. So far, there is nothing about Apache::Dynagzip in this problem really. I couldn't get Dynagzip to work correctly with a nph CGI script either. There is an option UseCGIHeadersFromScript but it appears to have no effect in the code. Right, UseCGIHeadersFromScript should not have any effect inside the Apache::Filter chain. There are simply no any CGI anymore since you switch to Apache::Filter that carries own requirements on how you should create HTTP headers in your script. You should consider appropriate changes in your script before switching. Otherwise, you can try to configure Apache::Dynagzip to serve your script as a CGI binary, and continue to enjoy the UseCGIHeadersFromScript option in your configuration if necessary. Thanks, Slava -- 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: Re: PerlTransHandler, Location
You were right, my firsts tests indicate that things are going well (i have to work more on it) with internal_redirect(). Simply i did not know the existence of these wonderful functions (methods). I have not understood why a Location header cannot work anyway, but i am fully happy with your help and this solution. Thanks a lot :D eps com estem wrote: Hi. I want to redirect to some uri one page. This can be accomplished easily in PerlTransHandler with $r- uri($new_uri); My problem is that this uri needs to be parsed again with the same module responsible of that. This is, i have a web page parse by module X that has to redirect to another uri that has to pass again by module X at the same PerlTransHandler phase. So $r- uri($new_uri); does not work because the new uri goes on after the PerlTransHandler phase, and it's not valid for me. None of this options has worked. What i am doing wrong? What i use in the past was a rude javascript printed in the web page that redirected automatically to the url. Now i want to use the modperl api to do it. I'm afraid I don't fully understand what you are trying to do, but it sounds as though $r-internal_redirect() is what you are after - it essentially mimics a browser redirect, placing the new request through the entire request cycle (including the PerlTransHandler) but without telling the browser about it. HTH --Geoff - Vuelve la quiniela. Ahora puedes jugar online y hacerte millonario http://sorteos.ya.com Ya.com ADSL Router Wi-Fi: Sólo 29,90 /mes + IVA*. Router + Antivirus y firewall ¡Gratis! http://acceso.ya.com/adsl/256router -- 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] Perl Sections in .htaccess files leak memory
Rici Lake wrote: In the course of trying to figure out why mod_info does not reveal directives added in PerlSections (see other email), I stumbled across the following problem: I created a simple seven-line .htaccess file, and did 100,000 requests to a file in the corresponding directory with ab. All processes were perfectly stable in memory consumption. Then I do the same thing with a Perl section in the .htaccess file. 100,000 requests later my 12 processes had grown from 6.5M to 25.5M Could you please post the 2 .htaccess files you've been using ? My analysis of this is that mod_perl's perl sections are *always* run in the pconf pool, rather than running in the request pool as would be normal for .htaccess files. Consequently, all directive parsing and config merging will use the pconf pool, effectively resulting in a permanent expansion of that pool. Hrm, that's quite odd, as I looked over the code and AFAIK, Perl sections in .htaccess will be running off parms-pool, and in the case of .htaccess files, that's r-pool. Can you tell me more about how you made the determination that it was using the pconf ? -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 signature.asc Description: OpenPGP digital signature
Re: PerlTransHandler, Location
Geoffrey Young wrote: eps com estem wrote: You were right, my firsts tests indicate that things are going well (i have to work more on it) with internal_redirect(). Simply i did not know the existence of these wonderful functions (methods). might I suggest, then, some of the mod_perl books listed on the project website: http://perl.apache.org/docs/offsite/books.html Geoff is too shy to advertise the book he wrote :) So I'll do it for him. You definitely want to get: http://perl.apache.org/docs/offsite/books.html#The_mod_perl_Developer_s_Cookbook as the first thing. You won't regret 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 -- 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
[mp2] mod_perl-1.99_16 make test failure on both_str_con_add.t, echo_block.t, and pseudo_http.t
Summary of problem: following failed during make test for mod_perl-1.99_16: t/filter/both_str_con_add.t t/protocol/echo_block.t t/protocol/pseudo_http.t The platform: - OpenBSD 3.5-stable (GENERIC) #0: Thu Aug 12 23:59:05 EDT 2004 (i.e., patched) - perl v5.8.2 built for i386-openbsd (standard install) - httpd-2.0.50, patched per http://mathforum.org/epigone/modperl/skamsmeechong/20040906221419.GA1725 [EMAIL PROTECTED] - mod_perl-1.99_16 (had to use gmake to make httpd and mod_perl) The dump: (sorry for the length) cd /usr/local/src/ make mod_perl.test.debug2 cd mod_perl-1.99_16 ; ulimit -n 128 gmake test TEST_VERBOSE=1 TEST_FILES=t/filter/both_str_con_add.t t/protocol/echo_block.t t/protocol/echo_filter.t t/protocol/pseudo_http.t 21 |tee ../.mod_perl.test.debug2.1.99_16 cd src/modules/perl gmake -f Makefile.modperl gmake[1]: Entering directory `/usr/local/src/mod_perl-1.99_16/src/modules/perl' gmake[1]: Nothing to be done for `all'. [lots of snips] gmake[3]: Leaving directory `/usr/local/src/mod_perl-1.99_16/xs/ModPerl/Const' gmake[2]: Leaving directory `/usr/local/src/mod_perl-1.99_16/xs/ModPerl' gmake[1]: Leaving directory `/usr/local/src/mod_perl-1.99_16/xs' /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -clean APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT= APACHE_TEST_USER= APACHE_TEST_APXS= \ /usr/bin/perl -Iblib/arch/Apache2 -Iblib/lib/Apache2 \ t/TEST -bugreport -verbose=1 t/filter/both_str_con_add.t t/protocol/echo_block.t t/protocol/echo_filter.t t/protocol/pseudo_http.t /usr/local/apache2/bin/httpd -d /usr/local/src/mod_perl-1.99_16/t -f /usr/local/src/mod_perl-1.99_16/t/conf/httpd.conf -D APACHE2 using Apache/2.0.50 (prefork MPM) waiting 120 seconds for server to start: .[Wed Sep 08 21:38:31 2004] [info] 26 Apache:: modules loaded [Wed Sep 08 21:38:31 2004] [info] 7 APR:: modules loaded [Wed Sep 08 21:38:31 2004] [info] base server + 20 vhosts ready to run tests ... waiting 120 seconds for server to start: ok (waited 15 secs) server jlf.mitretek.org:8529 started server jlf.mitretek.org:8530 listening (TestModperl::setupenv) server jlf.mitretek.org:8531 listening (TestModperl::merge) server jlf.mitretek.org:8532 listening (TestModperl::perl_options) server jlf.mitretek.org:8533 listening (TestVhost::config) server jlf.mitretek.org:8534 listening (TestProtocol::pseudo_http) server jlf.mitretek.org:8535 listening (TestProtocol::echo_filter) server jlf.mitretek.org:8536 listening (TestProtocol::echo_bbs2) server jlf.mitretek.org:8537 listening (TestProtocol::echo_bbs) server jlf.mitretek.org:8538 listening (TestProtocol::echo_timeout) server jlf.mitretek.org:8539 listening (TestProtocol::echo_block) server jlf.mitretek.org:8540 listening (TestPreConnection::note) server jlf.mitretek.org:8541 listening (TestHooks::startup) server jlf.mitretek.org:8542 listening (TestHooks::stacked_handlers2) server jlf.mitretek.org:8543 listening (TestHooks::hookrun) server jlf.mitretek.org:8544 listening (TestFilter::in_bbs_msg) server jlf.mitretek.org:8545 listening (TestFilter::both_str_con_add) server jlf.mitretek.org:8546 listening (TestFilter::in_bbs_inject_header) server jlf.mitretek.org:8547 listening (TestFilter::in_str_msg) server jlf.mitretek.org:8548 listening (TestDirective::perlrequire) server jlf.mitretek.org:8549 listening (TestDirective::perlmodule) server jlf.mitretek.org:8550 listening (TestDirective::perlloadmodule4) server jlf.mitretek.org:8551 listening (TestDirective::perlloadmodule5) server jlf.mitretek.org:8552 listening (TestDirective::perlloadmodule3) server jlf.mitretek.org:8553 listening (TestDirective::perlloadmodule6) t/filter/both_str_con_add1..4 # Running under perl version 5.008002 for openbsd # Current time local: Wed Sep 8 21:38:44 2004 # Current time GMT: Thu Sep 9 01:38:44 2004 # Using Test.pm version 1.24 ok 1 # expected: mod_perl # received: not ok 2 # Failed test 2 in t/filter/both_str_con_add.t at line 22 # t/filter/both_str_con_add.t line 22 is: ok t_cmp($reply, $str); # expected: 2.0 # received: not ok 3 # Failed test 3 in t/filter/both_str_con_add.t at line 22 fail #2 # expected: rules # received: not ok 4 # Failed test 4 in t/filter/both_str_con_add.t at line 22 fail #3 FAILED tests 2-4 Failed 3/4 tests, 25.00% okay t/protocol/echo_block1..3 # Running under perl version 5.008002 for openbsd # Current time local: Wed Sep 8 21:38:48 2004 # Current time GMT: Thu Sep 9 01:38:48 2004 # Using Test.pm version 1.24 ok 1 # expected: hello # received: not ok 2 # Failed test 2 in t/protocol/echo_block.t at line 19 # t/protocol/echo_block.t line 19 is: ok t_cmp($reply, $_); # expected: world # received: not ok 3 # Failed test 3 in t/protocol/echo_block.t at line 19 fail #2 FAILED tests 2-3 Failed 2/3 tests, 33.33% okay t/protocol/echo_filter...1..3 # Running under perl version 5.008002 for openbsd # Current time local: Wed Sep 8 21:38:52 2004 # Current time GMT: Thu
Re: [mp2] mod_perl-1.99_16 make test failure on both_str_con_add.t, echo_block.t, and pseudo_http.t
Fisher, James L. wrote: Summary of problem: following failed during make test for mod_perl-1.99_16: t/filter/both_str_con_add.t t/protocol/echo_block.t t/protocol/pseudo_http.t The platform: - OpenBSD 3.5-stable (GENERIC) #0: Thu Aug 12 23:59:05 EDT 2004 (i.e., patched) It's an bug in libapr which will hopefully will be fixed in 2.0.51. Just ignore those for now. -- __ 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: [mp2] mod_perl-1.99_16 make test failure on both_str_con_add.t, echo_block.t, and pseudo_http.t
Stas Bekman wrote:
Fisher, James L. wrote:
Summary of problem: following failed during make test for
mod_perl-1.99_16:
t/filter/both_str_con_add.t
t/protocol/echo_block.t
t/protocol/pseudo_http.t
The platform:
- OpenBSD 3.5-stable (GENERIC) #0: Thu Aug 12 23:59:05 EDT 2004 (i.e.,
patched)
It's an bug in libapr which will hopefully will be fixed in 2.0.51. Just
ignore those for now.
obvously we need to fix the tests to skip on *BSD/2.0.{47..50}, but it's
not clear when the dust settles down to know how to do it right.
--
__
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: Win32 build problems libapreq2-2.04_03-dev
After updating both Apache2 and mod_perl on the W2K Server, there are still
some problems in building libarpeq2-2.04_03-dev on Win32.
Current software levels are:
Apache/2.0.50 (Win32) mod_perl/1.99_16 Perl/v5.8.4 Server
When invoking 'nmake perl_glue', 'nmake perl_test', or nmake perl_install
each will return the same error message. Nmake correctly detects that
Apache2 is installed at 'E:\Apache2'.
.
.
.
nmake perl_glue
writing...xs//Makefile.PL
writing...xs/Apache/Makefile.PL
[ info] generating script t/TEST
Can't find the mod_perl include dir (reason: path D:\Apache2\include doesn't
exi
st) at E:/Perl/site/lib/Apache2/Apache/Build.pm line 1715.
NMAKE : fatal error U1077: 'E:\Perl\bin\perl.exe' : return code '0x2'
If this error message is indeed attempting to find files in the directory,
'D:\Apache2\include', it won't because the directory doesn't exist. Its not
clear to me where the build process is picking up the reference to
'D:\Apache2\include'.
Scanning both the directories 'E:\Perl' and 'E:\Apache2' for 'D:\Apache2',
the file
'E:\Perl\site\lib\Apache2\auto\libaprext\extralibs.ld' was found to contain
references to 'D:\Apache2\lib'. After correcting the invalid references, the
problem still exists.
Windows XP Pro is having the exact same problem too.
Thanks, Craig
-Original Message-
From: Randy Kobes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 01, 2004 21:15
To: Craig Dayton
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: Win32 build problems libapreq2-2.04_03-dev
On Wed, 1 Sep 2004, Craig Dayton wrote:
Hi Randy,
For the Windows 2000 Server system its running mod_perl/1.99_14, so
this explains the missing file problem. The current
mod_perl will get
built on this system.
Great - that should resolve that problem ...
I'm not sure what the problem is here - all of the Apache
references
above use E:\ as the drive, which appears correct. When you did the
'perl Makefile.PL', did a confirmation come up asking you which
Apache to use? If so, was it the correct one, including the drive
letter?
Yes Yes.
I tried 'perl Makefile.PL' and it found the correct Apache2 location
and I responded 'yes' to the prompt. Also, I tried 'perl Makefile.PL
--with-Apache2=E:/Apache2'. In both cases its trying to find Apache
on a another drive. In the first instance, it was expecting Apache2
on drive Z: which was a valid network drive. After disconnecting the
network drive Z:, the second attempt was expecting Apache to be on
drive D: (CD-ROM).
I take it this is at the
nmake test
stage? I can't see why it would be looking in different
drives at this point; it's already found Apache ...
[ debug] can't figure out Apache revision, from string:
'', using
a non-existin g revision 0
Its interesting that an empty string is referenced in the output
above.
Do you have an Apache/TestConfigData.pm somewhere on your system,
either in the main Perl tree or under a .apache-test
directory under,
eg, C:\ or E:\? If so, does it help if you move it out of
the way and
run the tests again?
No. TestConfigData.pm is only located at 'E:\Perl\site\lib\Apache\'.
Looking at this module, I see the following:
$Apache::TestConfigData::vars = {'httpd' =
'\Apache2\bin\Apache.EXE',}; I tried changing this to
'E:\Apache2\bin\Apache.EXE'. This didn't help.
What if you tried moving this file completely away?
I tried adding 'E:\Apache2\bin' to the Path environmental variable
just see if that might help. It didn't. The 'nmake test' is still
failing for the same apparent reason of not being able to resolve
Apache2's location. Also, I find it interesting that
apxs.bat failed
its 3 query attempts too.
Thanks, Craig
The problem with apxs.bat on Win32 is related to something
that changed recently in Apache-Test; I haven't been able to
trace why these warnings are arising ...
To try to eliminate one possibility, what happens if you
move $APACHE2\bin\apxs.bat somewhere outside of the PATH,
and then do
nmake perl_glue
nmake perl_test
That should work - it's only the
nmake test
target that requires apxs.
Also, there's a file $APACHE2\build\config_vars.mak with
various settings used by apxs - for those that reference a
drive, is the letter correct?
--
best regards,
randy
--
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
cvs commit: modperl-2.0 Changes
stas2004/09/08 16:41:17
Modified:src/modules/perl modperl_util.c
.Changes
Log:
$s-log-warn and other $s-log-foo are now logging to the right vhost
server and not the global one. modperl_sv2server_rec was broken.
Revision ChangesPath
1.78 +6 -3 modperl-2.0/src/modules/perl/modperl_util.c
Index: modperl_util.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.77
retrieving revision 1.78
diff -u -u -r1.77 -r1.78
--- modperl_util.c25 Aug 2004 20:57:14 - 1.77
+++ modperl_util.c8 Sep 2004 23:41:16 - 1.78
@@ -87,9 +87,12 @@
MP_INLINE server_rec *modperl_sv2server_rec(pTHX_ SV *sv)
{
-return SvOBJECT(sv) ?
-(server_rec *)SvObjIV(sv) :
-modperl_global_get_server_rec();
+if (SvOBJECT(sv) || (SvROK(sv) (SvTYPE(SvRV(sv)) == SVt_PVMG))) {
+return (server_rec *)SvObjIV(sv);
+}
+else {
+return modperl_global_get_server_rec();
+}
}
MP_INLINE request_rec *modperl_sv2request_rec(pTHX_ SV *sv)
1.475 +4 -0 modperl-2.0/Changes
Index: Changes
===
RCS file: /home/cvs/modperl-2.0/Changes,v
retrieving revision 1.474
retrieving revision 1.475
diff -u -u -r1.474 -r1.475
--- Changes 8 Sep 2004 04:10:09 - 1.474
+++ Changes 8 Sep 2004 23:41:17 - 1.475
@@ -12,6 +12,10 @@
=item 1.99_17-dev
+$s-log-warn and other $s-log-foo are now logging to the right
+vhost server and not the global one. modperl_sv2server_rec was
+broken. [Stas]
+
Fix a glue_pod make target bug, when .pm file doesn't exist,
e.g. ThreadMutex.pm is not created on unless
$apr_config-{HAS_THREADS} [Stas]
cvs commit: modperl-2.0/xs/Apache/Log Apache__Log.h
stas2004/09/08 16:41:53
Modified:xs/Apache/Log Apache__Log.h
Log:
style
Revision ChangesPath
1.18 +2 -2 modperl-2.0/xs/Apache/Log/Apache__Log.h
Index: Apache__Log.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/Log/Apache__Log.h,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -u -r1.17 -r1.18
--- Apache__Log.h 23 Aug 2004 18:48:53 - 1.17
+++ Apache__Log.h 8 Sep 2004 23:41:53 - 1.18
@@ -273,7 +273,7 @@
dXSARGS;
request_rec *r = NULL;
server_rec *s = NULL;
-int i=0;
+int i = 0;
char *errstr = NULL;
SV *sv = Nullsv;
STRLEN n_a;
@@ -305,7 +305,7 @@
}
if (s) {
-i=1;
+i = 1;
}
else {
s = modperl_global_get_server_rec();
cvs commit: modperl-2.0/t/response/TestModules reload.pm
stas2004/09/08 16:46:39 Modified:t/response/TestModules reload.pm Log: avoid the reload debug noise in the error_log Revision ChangesPath 1.2 +2 -2 modperl-2.0/t/response/TestModules/reload.pm Index: reload.pm === RCS file: /home/cvs/modperl-2.0/t/response/TestModules/reload.pm,v retrieving revision 1.1 retrieving revision 1.2 diff -u -u -r1.1 -r1.2 --- reload.pm 24 Aug 2004 17:36:56 - 1.1 +++ reload.pm 8 Sep 2004 23:46:39 - 1.2 @@ -9,7 +9,7 @@ my $r = shift; eval use Apache::Reload::Test; - + Apache::Reload::Test::run($r); return Apache::OK; @@ -20,6 +20,6 @@ PerlModule Apache::Reload PerlInitHandler Apache::TestHandler::same_interp_fixup Apache::Reload -PerlSetVar ReloadDebug On +PerlSetVar ReloadDebug Off PerlSetVar ReloadConstantRedefineWarnings Off PerlSetVar ReloadAll Off
