Re: very old bug report about internal_redirect
:-> "Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes:
>> With this setup, the error message changes:
>> Now I have:
>> [Sun Nov 9 20:17:26 2003] [error] Can't call method "content_type"
>> on an undefined value at /usr/local/lib/site_perl/bug130883/Impl1.pm
>> line 10.
>> when I try to access /R
> that error makes more sense.
> here, what is happening is that your handler is being called, but not
> as a method handler - meaning the
>my $self = shift;
> in Impl1::handler() is getting $r, thus leaving the call to
>my $req = shift;
> with an empty argument list.
> ok, if you could try a few things for me, that would be great.
> first, try prototyping all the method handlers with
> sub handler : method {
> instead of using ($$).
Hello, sorry for the late reply but I had 2 very bad days at work :(
I've tried replacing '($$)' with ': method'
and I now get this when accessing /R
[Wed Nov 12 08:11:37 2003] [error] Can't locate object method
"internal_redirect" via package "bug130883::Redir" at
/usr/local/lib/site_perl/bug130883/Redir.pm line 9.
I'll try the patch later.
Pf
> next, try applying the attached patch and see if it helps at all (both
> with $$ and : method).
> thanks
> --Geoff
> Index: src/modules/perl/mod_perl.c
> ===
> RCS file: /home/cvspublic/modperl/src/modules/perl/mod_perl.c,v
> retrieving revision 1.147
> diff -u -r1.147 mod_perl.c
> --- src/modules/perl/mod_perl.c 2 Oct 2003 21:30:35 - 1.147
> +++ src/modules/perl/mod_perl.c 9 Nov 2003 21:59:05 -
> @@ -1231,20 +1231,33 @@
> if (gvp) cv = GvCV(gvp);
> }
> +if (cv != NULL) {
> + is_method = perl_cv_ismethod(cv);
> +}
> +
> +MP_TRACE_h(fprintf(stderr, "checking if `%s' is a method...%s\n",
> +sub, (is_method ? "yes" : "no")));
> +SvREFCNT_dec(sv);
> +return is_method;
> +}
> +
> +int perl_cv_ismethod(CV *cv)
> +{
> +int is_method=0;
> +
> #ifdef CVf_METHOD
> if (cv && (CvFLAGS(cv) & CVf_METHOD)) {
> is_method = 1;
> }
> #endif
> +
> if (!is_method && (cv && SvPOK(cv))) {
> is_method = strnEQ(SvPVX(cv), "$$", 2);
> }
> -MP_TRACE_h(fprintf(stderr, "checking if `%s' is a method...%s\n",
> -sub, (is_method ? "yes" : "no")));
> -SvREFCNT_dec(sv);
> return is_method;
> }
> +
> #endif
> void mod_perl_noop(void *data) {}
> @@ -1486,6 +1499,7 @@
> HV *stash = Nullhv;
> SV *pclass = newSVsv(sv), *dispsv = Nullsv;
> CV *cv = Nullcv;
> +GV *gv = Nullgv;
> char *method = "handler";
> int defined_sub = 0, anon = 0;
> char *dispatcher = NULL;
> @@ -1620,8 +1634,27 @@
> #endif
> }
> else {
> - MP_TRACE_h(fprintf(stderr, "perl_call: handler is a %s\n",
> - dispatcher ? "dispatcher" : "cached CV"));
> +if (!dispatcher) {
> + MP_TRACE_h(fprintf(stderr, "perl_call: handler is a cached CV\n"));
> +#ifdef PERL_METHOD_HANDLERS
> + cv = sv_2cv(sv, &stash, &gv, FALSE);
> +
> + if (cv != NULL) {
> + is_method = perl_cv_ismethod(cv);
> + }
> +
> + if (is_method) {
> + sv_setpv(pclass, HvNAME(stash));
> + method = GvNAME(CvGV(cv));
> + }
> +
> + MP_TRACE_h(fprintf(stderr, "checking if CV is a method...%s\n",
> + (is_method ? "yes" : "no")));
> +#endif
> +}
> + else {
> + MP_TRACE_h(fprintf(stderr, "perl_call: handler is a dispatcher\n"));
> +}
> }
> callback:
> --
> Reporting bugs: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
--
---
Pierfrancesco Caci | ik5pvx | mailto:[EMAIL PROTECTED] - http://gusp.dyndns.org
Firenze - Italia | Office for the Complication of Otherwise Simple Affairs
Linux penny 2.6.0-test9 #1 Fri Oct 31 22:51:12 CET 2003 i686 GNU/Linux
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
mod_perl
I am using Apache and mod_perl that comes out of the box with Red Hat 9. httpd -v Server version: Apache/2.0.40 Server built: Feb 25 2003 05:01:56 I have set up three separate Virtual Hosts which I use for my site. One of the hosts is for my personal testing, one is for QA and one is the live system. I have one cgi file that I run for each virtual host, each from a different directory, but with the same name. Sometimes when I change the cgi program for one of the virtual hosts the change appears in one of the other virtual hosts. I suspect that there is a problem with the caching mechanism. I know that I haven't written the file to the wrong directory because if I restart http, the problem disappears. I know that this is not the most up-to-date version of Apache, but I have looked through the release notes and didn't see anything relevant. Has anyone else had a problem like this, and if so, what was the solution. Thanks Peter -- Peter Gordon Tel: (972) 8 9432430 Ext: 129 Cell phone: 054 438029 Fax: (972) 8 9432429 Valor Ltd, PO Box 152, Yavne 70600, Israel Email: [EMAIL PROTECTED] -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: MP2 -> newbie question, virtual hosts
On Tue, 11 Nov 2003, Larry Leszczynski wrote: > I think you mean: > > my ($vhostname,$vhostuser,$vhosthomedir,$vhostip) = split / /, $_; Oops. I shall now skulk off to a dark corner and be embarrassed. The original script I had to do this was correct; I muddled it in transposition. Nothing like staring at the same code again, and again, to blind yourself to the problem, is there? Thanks for that, Larry. It now works, so I will now be able to do some serious testing to see if this method is worth following. Graeme -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl and mysql
I'm quite sure that this happens because you're using mod_perl AND php compiled into the same apache. I've been running into this kind of trouble several times (on different machines with different apache/mod_perl/php versions - mod_perl was always compiled statically. I tried php statically and dynamically with built-in mysql-support and linked to my installed mysql libraries - nothing helped). I finally gave up on this and am now running two separate apache servers (one for php, one for mod_perl) on my machine which kinda sucks :( -- Cheers, Tobias Zitat von Global Junk <[EMAIL PROTECTED]>: > I'm running Linux Apache/1.3.26 (Unix) mod_perl/1.26 > PHP/4.2.3 and MySQL. > > I'm trying to write a simple web (perl) application > that accesses a mysql database. I'm using DBI(). > When I access the site under normal Perl it works. > When I access the site under Mod_Perl I get: > > child pid 20524 exit signal Segmentation fault (11), > possible coredump in /usr/local/apache > > Does anyone have any ideas or links to help with > Mod_Perl and MySQL running together? > > Thanks. > > __ > Do you Yahoo!? > Protect your identity with Yahoo! Mail AddressGuard > http://antispam.yahoo.com/whatsnewfree > > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > > > --- http://www.funkreich.de // may the funk be with you -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
Stas Bekman wrote: Marc Slagle wrote: [...] If you need any more information, please let us know. I went through the pain of installing all these prerequisited just to run your handlers, but it works just fine for me. I've tried to match the perl-5.8.0 build and the only difference I think is that I used the latest modperl from cvs. Also all the latest xml/xslt libs. Let me know if you want me to provide you some info about the used components. Actually, no, I do get the segfault, which is good. I forgot that I need to run it several times. More on this later... __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl
peter wrote: I am using Apache and mod_perl that comes out of the box with Red Hat 9. httpd -v Server version: Apache/2.0.40 Server built: Feb 25 2003 05:01:56 I have set up three separate Virtual Hosts which I use for my site. One of the hosts is for my personal testing, one is for QA and one is the live system. I have one cgi file that I run for each virtual host, each from a different directory, but with the same name. Sometimes when I change the cgi program for one of the virtual hosts the change appears in one of the other virtual hosts. I suspect that there is a problem with the caching mechanism. I know that I haven't written the file to the wrong directory because if I restart http, the problem disappears. I know that this is not the most up-to-date version of Apache, but I have looked through the release notes and didn't see anything relevant. Has anyone else had a problem like this, and if so, what was the solution. http://perl.apache.org/docs/1.0/guide/config.html#A_Script_From_One_Virtual_Host_Calls_a_Script_with_the_Same_Path_From_the_Other_Virtual_Host It's almost the same in ModPerl::Registry in mod_perl 2.0, though since I just replaced Apache::Registry with ModPerl::RegistryCooker, it's: $ModPerl::RegistryCooker::NameWithVirtualHost = 1; I think I need to change that to have this variable specific to each class. So there will be: $ModPerl::Registry::NameWithVirtualHost, $ModPerl::PerlRun::NameWithVirtualHost, etc. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl 1.99_11 errors with make test
Sorry Stas, but I guess I screwed it up.
I updated my system yesterday (as planned) from SuSE 8.3 to 9.0
and the errors are gone !
Nevertheless, I tried to bring this newly installed system to the level
I had before (kernel, perl,...) but there's still none of the errors left.
Even liabreq2 is now performing the test without any complaints !
The only difference I still have is the gcc version 3.3 -> 3.3.1
and the removed libdirs from the old perl version 5.8.0
Does this give you any ideas ???
I can't believe that the old perl was causing this, more so I think the
compiler version or a srewed up config on my development system (which is
even more likely) !
Ok, I still have a problem with test but nothing in comparison to the
problems I had before.
Doing the Modperl-Registry test I get the following
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST
*** root mode: changing the files ownership to 'nobody' (65534:65533)
*** /usr/bin/perl -e ' require POSIX; POSIX::setuid(65534);
POSIX::setgid(65533); print -r
q{/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t} && -w _ && -x _ ?
q{OK} : q{NOK}; '
*** result: OK
/usr/local/apache2/bin/httpd -d
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t -f
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.48 (worker MPM)
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 28 secs)
server localhost:8529 started
206ok
304ok
404ok
500ok
bad_scriptsok
basic..ok 3/15# Failed test 4 in basic.t at line 39
basic..NOK 4# Failed test 5 in basic.t at line 39 fail #2
basic..NOK 5# Failed test 6 in basic.t at line 39 fail #3
basic..FAILED tests 4-6
Failed 3/15 tests, 80.00% okay
cgiok
closureok
flush..skipped
all skipped: cannot find module 'deflate'
perlrun_requireok
redirect...ok
special_blocks.ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
basic.t 153 20.00% 4-6
1 test skipped.
*** server localhost:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
##
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST 'basic.t' -v
*** root mode: changing the files ownership to 'nobody' (65534:65533)
*** /usr/bin/perl -e ' require POSIX; POSIX::setuid(65534);
POSIX::setgid(65533); print -r
q{/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t} && -w _ && -x _ ?
q{OK} : q{NOK}; '
*** result: OK
/usr/local/apache2/bin/httpd -d
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t -f
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.48 (worker MPM)
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 16 secs)
server localhost:8529 started
basic1..15
# Running under perl version 5.008002 for linux
# Current time local: Wed Nov 12 11:10:30 2003
# Current time GMT: Wed Nov 12 10:10:30 2003
# Using Test.pm version 1.24
# testing : ModPerl::PerlRun basic cgi test
# expected: ok
# received: ok
ok 1
# testing : ModPerl::Registry basic cgi test
# expected: ok
# received: ok
ok 2
# testing : ModPerl::RegistryBB basic cgi test
# expected: ok
# received: ok
ok 3
# testing : ModPerl::PerlRun non-executable file
# expected: 403 Forbidden
# received: 200 OK
not ok 4
# Failed test 4 in basic.t at line 39
# testing : ModPerl::Registry non-executable file
# Failed test 5 in basic.t at line 39 fail #2
# expected: 403 Forbidden
# received: 200 OK
not ok 5
# testing : ModPerl::RegistryBB non-executable file
# Failed test 6 in basic.t at line 39 fail #3
# expected: 403 Forbidden
# received: 200 OK
not ok 6
# testing : ModPerl::PerlRun mod_cgi-like environment pre-set
# expected: foo=bar
# received: foo=bar
ok 7
# testing : ModPerl::Registry mod_cgi-like environment pre-set
# expected: foo=bar
# received: foo=bar
ok 8
# testing : ModPerl::RegistryBB mod_cgi-like environment pre-set
# expected: foo=bar
# received: foo=bar
ok 9
# testing : ModPerl::PerlRun mod_cgi-like environment pre-set
# expected: it works
# received: it works
ok 10
# testing : ModPerl::Registry mod_cgi-like environment pre-set
# expected: it works
# received: it works
ok 11
# testing : ModPerl::RegistryBB mod_cgi-like environment pre-set
# expected: it works
# received: it works
ok 12
# testing : ModPerl::Registry->handler mod_cgi-like environment pre-set
# expected: foo=bar
# received: foo=bar
ok 13
# testing : $r->content_type('text/plain')
# expected: ok
# received: ok
ok 14
# testing : script's content-type
# expected: text/plain
# received: text
Re: mod_perl 1.99_11 errors with make test
And again sorry, even this test is successful if the no_executable.pl file
is really not executable !!
So as I said before sorry for the hassle and thanks a lot for your support
!
Swen
|-+>
| | Swen |
| | Schillig/Germany/|
| | [EMAIL PROTECTED]|
| ||
| | 11/12/2003 11:55 |
| | AM |
| ||
|-+>
>--|
|
|
| To: Stas Bekman <[EMAIL PROTECTED]>
|
| cc: [EMAIL PROTECTED]
|
| Subject: Re: mod_perl 1.99_11 errors with make test
|
|
|
|
|
>--|
Sorry Stas, but I guess I screwed it up.
I updated my system yesterday (as planned) from SuSE 8.3 to 9.0
and the errors are gone !
Nevertheless, I tried to bring this newly installed system to the level
I had before (kernel, perl,...) but there's still none of the errors left.
Even liabreq2 is now performing the test without any complaints !
The only difference I still have is the gcc version 3.3 -> 3.3.1
and the removed libdirs from the old perl version 5.8.0
Does this give you any ideas ???
I can't believe that the old perl was causing this, more so I think the
compiler version or a srewed up config on my development system (which is
even more likely) !
Ok, I still have a problem with test but nothing in comparison to the
problems I had before.
Doing the Modperl-Registry test I get the following
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST
*** root mode: changing the files ownership to 'nobody' (65534:65533)
*** /usr/bin/perl -e ' require POSIX; POSIX::setuid(65534);
POSIX::setgid(65533); print -r
q{/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t} && -w _ && -x _ ?
q{OK} : q{NOK}; '
*** result: OK
/usr/local/apache2/bin/httpd -d
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t -f
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.48 (worker MPM)
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 28 secs)
server localhost:8529 started
206ok
304ok
404ok
500ok
bad_scriptsok
basic..ok 3/15# Failed test 4 in basic.t at line 39
basic..NOK 4# Failed test 5 in basic.t at line 39 fail #2
basic..NOK 5# Failed test 6 in basic.t at line 39 fail #3
basic..FAILED tests 4-6
Failed 3/15 tests, 80.00% okay
cgiok
closureok
flush..skipped
all skipped: cannot find module 'deflate'
perlrun_requireok
redirect...ok
special_blocks.ok
Failed Test Stat Wstat Total Fail Failed List of Failed
---
basic.t 153 20.00% 4-6
1 test skipped.
*** server localhost:8529 shutdown
!!! error running tests (please examine t/logs/error_log)
##
*** setting ulimit to allow core files
ulimit -c unlimited; t/TEST 'basic.t' -v
*** root mode: changing the files ownership to 'nobody' (65534:65533)
*** /usr/bin/perl -e ' require POSIX; POSIX::setuid(65534);
POSIX::setgid(65533); print -r
q{/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t} && -w _ && -x _ ?
q{OK} : q{NOK}; '
*** result: OK
/usr/local/apache2/bin/httpd -d
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t -f
/development/PERL/mod_perl-1.99_11/ModPerl-Registry/t/conf/httpd.conf
-DAPACHE2 -DPERL_USEITHREADS
using Apache/2.0.48 (worker MPM)
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 16 secs)
server localhost:8529 started
basic1..15
Re: [mp2] OutputFilter with UTF-8 characters
Hi Stas, On Tue, 11 Nov 2003, Stas Bekman wrote: > [snip] > Who would think that a response handler: > >print while ; > > would affect the special vars in the filter called by print. Who indeed! > [snip] > So let's decide how do we act upon this: > [snip] > I'm not sure whether we should make a special case for $_ and localize it > behind the scenes. I wonder if someone may find this to be a problem, if they > try to use the non-licalized $_ for its side-effects. Many experienced Perl programmers will use special variables almost without thinking. Things like this are frightening, and it's why I'm sticking to mod_perl 1.x while continuing to read the experiences of other, more adventurous souls. I think it's necessary to make mod_perl behave like Perl as far as is possible. The chapter on mod_perl traps is big enough already, let's not let it get any bigger. 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::SessionManager and Apache::DBI
On Mon, 10 Nov 2003 14:24:11 +0800
Byron Hammond <[EMAIL PROTECTED]> wrote:
Hi Byron,
>Hi Enrico,
>
>Thanks for the great work on Apache::SessionManager.
>I started using Apache::Session thinking I didn't need
>Apache::SessionManager. How wrong I was :)
>I am using mod_perl with Apache::DBI for persistent db
>connections and was wondering if I can use this with
>Apache::SessionManager?
Yes, you can. Transparently of course.
>Since I already have a database handle, I can use
>the following code to get Apache::Session to use it.
>
>my %session;
>tie %session, 'Apache::Session::Postgres', undef,
>{
> Handle => $dbh,
> Commit => 1,
>};
>
>
>I was hoping to make use of my persistent database
>connection with Apache::SessionManager but the following
>doesn't seem to work.
>
>PerlSetVar SessionManagerStore Postgres
>PerlSetVar SessionManagerStoreArgs "Handle => $dbh, Commit => 1"
Mmmh, this is the wrong way! :-)
>Basically, as long as Apache::SessionManager calls DBI->connect
>with the same parameters that I do when I setup my initial
>persistent connection, I'll be ok. I was hoping to not
>dive into code to enforce this though.
Apache::DBI overrides DBI 'connect' and 'disconnect' methods and it intercepts
all related calls (including Apache::SessionManager DBI calls) by returning
cached connections, if any.
Simply add a line like:
PerlModule Apache::DBI
in your httpd.conf, or:
use Apache::DBI;
in a startup.pl file.
However, remember that you _must_ load Apache::DBI module before DBI or any
module that uses it!
For testing purpose, you can enable perl-status console by putting (before
loading Apache::DBI) lines like:
SetHandler perl-script
PerlHandler Apache::Status
# or PerlResponseHandler Apache::Status in mod_perl 2
You will see in the 'DBI connections' page, the cached datasource (in current
child) used by Apache::Session::* plugin datastore you've chosen. (I also
suggest to start httpd in single mode with -X option)
by
- Enrico
PS: I'm packaging Apache::SessionManager in order to support mod_perl 2 API (now
you can use A::SM under Apache::compat layer) and I'll add a section on cookpod
to explain how to use A::SM with A::DBI. Thanks for your observation! ;-)
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Data lost when browser refreshed
I got these errors when I did perl MakeFile.pl for mod_perl-1.99_11 I have a standard redhat 8.0 install with the latest rpms. DO I need to uninstall apache, mod_perl and do a source install? I'm afraid of chasing this all over the place. APXS doesn't appear to be on my system. * WARNING * Your Perl is configured to link against libgdbm, but libgdbm.so was not found. You could just symlink it to /usr/lib/libgdbm.so.2.0.0 * WARNING * !!! Unable to determine server version, aborting. !!! Please specify MP_APXS or MP_AP_PREFIX. APXS (/usr/sbin/apxs) query for SBINDIR failed APXS (/usr/sbin/apxs) query for TARGET failed APXS (/usr/sbin/apxs) query for SYSCONFDIR failed Original Message Follows From: Stas Bekman <[EMAIL PROTECTED]> To: Tom Conway <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] Subject: Re: Data lost when browser refreshed Date: Tue, 11 Nov 2003 17:18:31 -0800 Tom Conway wrote: I'm just starting with mod_perl. I converted my cgi scripts for mod_perl usage. They work fine as plain cgi. When i go from one screen to another via submit or link, or just refresh a couple of times my data disappears. No errors, just a blank form. I have no idea what is wrong. First of all, please go and get mp-1.99_11 [1], 1.99_05 is *very* old and lots of bugs were fixed since then. If you still have a problem see: http://perl.apache.org/bugs/ 1) http://perl.apache.org/download/source.html#Development_mod_perl_2_0_Source_Distribution __ 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 _ From Beethoven to the Rolling Stones, your favorite music is always playing on MSN Radio Plus. No ads, no talk. Trial month FREE! http://join.msn.com/?page=offers/premiumradio -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[mp2] libapreq2 segmentation fault
Hi,
i has set up a solaris 9 system which the following components:
apache 2.0.48
modperl 1.99_11
lxml2 2.5.10
lxslt 1.0.32
libapreq2 2.01-dev
The instalation was done as described in the readme. Furthermore there is a
PerlAccessHandler. Everytime if i am requesting a page which will
controlled by this handler this error message:
[Wed Nov 12 11:03:26 2003] [notice] child pid 381 exit signal Segmentation
fault (11)' occurs in my error.log
Has anyone any idea?
Thanks
Wolfgang
package My::TicketHandler;
use strict;
use warnings;
use Apache::Const;
use Apache::Cookie;
sub handler {
my $r = shift;
my $s = $r->server;
my $ticket = Apache::Cookie->new (
$r,
-name => "Test",
-value => "Hansi"
);
$s->log_error("cookie");
}
1
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: very old bug report about internal_redirect
I've tried replacing '($$)' with ': method'
and I now get this when accessing /R
[Wed Nov 12 08:11:37 2003] [error] Can't locate object method
"internal_redirect" via package "bug130883::Redir" at
/usr/local/lib/site_perl/bug130883/Redir.pm line 9.
looks like you added the :method tag to bug130883::Redir::handler(), which
wasn't originally a method handler in the code you posted:
Redir.pm:
# Redir
package bug130883::Redir;
use Apache::Constants qw(:common);
sub handler
{
my $req = shift;
$req->internal_redirect("/1");
return OK;
}
1;
I'll try the patch later.
that would be a help. don't forget that you'll need to apply it to the
mod_perl.c in your apache source tree, or otherwise apply it to your
mod_perl souces, 'make realclean', and start from scratch. while you're
rebuilding mod_perl, it might be useful to add PERL_TRACE=1 and PERL_DEBUG=1
to your build, for debugging purposes (not for production, of course :)
I'll be away for the next week and a half, but if the patch doesn't work
I'll take a real look at this on the 24th (feel free to remind me then :)
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl and mysql
At 06:46 PM 11/11/2003 +, Andrew Green wrote: >On Tue, 11 Nov 2003 18:19:31 + (GMT), Ged Haywood wrote: > >> If you're using 5.8.0 right now you're probably best advised >> to wait for Perl 5.8.2, as 5.8.1 has a few issues - but it does work >> OK. > >Really? Is it ill-advised to use 5.8.1 in a production mod_perl >environment? I'm in the process of setting up a new server, and I'd >like to make sure the UTF8 handling is as good as it can be, and it'll >be doing a fair amount of XML work. And I'll be using MySQL too. Well, my older production machines are using 5.6.1 with mod_perl and that has been working very well for 8 months on VERY heavily used servers. After everything was debugged one machine has been up for 186 days with no trouble at all. Newer production machines are using Perl 5.8.1 as is my development machine, after many issues, hassles and downright nasty problems with 5.8.0 I moved to 5.8.1. Perl, Apache and mod_perl were all built locally. Perl 5.8.2 is out now for at least a week. I have not heard of any issues relating to its use. john >Cheers, >Andrew. > >-- >Reporting bugs: http://perl.apache.org/bugs/ >Mail list info: http://perl.apache.org/maillist/modperl.html -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: very old bug report about internal_redirect
:-> "Geoffrey" == Geoffrey Young <[EMAIL PROTECTED]> writes: >> I've tried replacing '($$)' with ': method' >> and I now get this when accessing /R >> [Wed Nov 12 08:11:37 2003] [error] Can't locate object method >> "internal_redirect" via package "bug130883::Redir" at >> /usr/local/lib/site_perl/bug130883/Redir.pm line 9. > looks like you added the :method tag to bug130883::Redir::handler(), > which wasn't originally a method handler in the code you posted: Uh, sorry. I corrected it and now I get this one: [Wed Nov 12 16:23:05 2003] [error] Can't call method "content_type" on an undefined value at /usr/local/lib/site_perl/bug130883/Impl1.pm line 10. >> I'll try the patch later. > that would be a help. don't forget that you'll need to apply it to > the mod_perl.c in your apache source tree, or otherwise apply it to > your mod_perl souces, 'make realclean', and start from scratch. while > you're rebuilding mod_perl, it might be useful to add PERL_TRACE=1 and > PERL_DEBUG=1 to your build, for debugging purposes (not for > production, of course :) The Debian Apache maintainer prepared me a patched version that I'll try as soon as possible. > I'll be away for the next week and a half, but if the patch doesn't > work I'll take a real look at this on the 24th (feel free to remind me > then :) No problem, I won't be at home till the 21st, and from work I don't have that much time to do this. Pf > --Geoff > -- > Reporting bugs: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html -- --- Pierfrancesco Caci | ik5pvx | mailto:[EMAIL PROTECTED] - http://gusp.dyndns.org Firenze - Italia | Office for the Complication of Otherwise Simple Affairs Linux penny 2.6.0-test9 #1 Fri Oct 31 22:51:12 CET 2003 i686 GNU/Linux -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] libapreq2 segmentation fault
Wolfgang Kubens <[EMAIL PROTECTED]> writes:
> Has anyone any idea?
See if this patch helps. Do a
% make clean && make test
in the base directory after applying the patch, so the perl glue
gets rebuilt properly with the patched Apache__Cookie.h.
Index: glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h
===
RCS file: /home/cvs/httpd-apreq-2/glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h,v
retrieving revision 1.15
diff -u -r1.15 Apache__Cookie.h
--- glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h 17 Oct 2003 14:23:29 -
1.15
+++ glue/perl/xsbuilder/Apache/Cookie/Apache__Cookie.h 12 Nov 2003 15:28:34 -
@@ -154,7 +154,7 @@
XSRETURN_UNDEF;
c = apreq_value_to_cookie(apreq_xs_sv2(cookie,ST(0)));
-p = apreq_env_pool(apreq_xs_sv2env(ST(0)));
+p = apreq_env_pool(apreq_xs_sv2env(SvRV(ST(0;
for (j = 1; j + 1 < items; j += 2) {
STRLEN alen, vlen;
--
Joe Schaefer
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: very old bug report about internal_redirect
> looks like you added the :method tag to bug130883::Redir::handler(), > which wasn't originally a method handler in the code you posted: Uh, sorry. I corrected it and now I get this one: [Wed Nov 12 16:23:05 2003] [error] Can't call method "content_type" on an undefined value at /usr/local/lib/site_perl/bug130883/Impl1.pm line 10. good, that's the same error. well, not good, but ok :) The Debian Apache maintainer prepared me a patched version that I'll try as soon as possible. cool. No problem, I won't be at home till the 21st, and from work I don't have that much time to do this. that's ok. as long as you can be patient we'll get it fixed. I promise it's on the top of my list when I return. --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: MP2 -> newbie question, virtual hosts
Hi Graeme - Don't be embarrassed - we've all been there before! :-) Larry > On Tue, 11 Nov 2003, Larry Leszczynski wrote: > > I think you mean: > > > > my ($vhostname,$vhostuser,$vhosthomedir,$vhostip) = split / /, $_; > > Oops. > > I shall now skulk off to a dark corner and be embarrassed. The > original script I had to do this was correct; I muddled it in > transposition. Nothing like staring at the same code again, and again, > to blind yourself to the problem, is there? -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Running Mkbootstrap for Apache::Symbol - fails MP1.29
I'm trying to do a new install of apache and mod_perl on a Red Hat Linux box. I've build my own perl 5.8.1 in /opt/. This is the first time I've had a build fail in years. Red Hat Enterprise Linux ES release 2.1 (Panama) Apache 1.3.29 mod_perl 1.29 perl -V: Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.4.9-e.27, archname=i686-linux uname='linux server1.tristanmedia.net 2.4.9-e.27 #1 tue aug 5 15:59:55 edt 2003 i686 unknown ' config_args='-Dprefix=/opt/perl-5.8.1 -des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-118.7.2)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Oct 16 2003 12:06:43 %ENV: PERL5LIB=".:/home/bhoggard/dev/artcat/lib" @INC: . /home/bhoggard/dev/artcat/lib /opt/perl-5.8.1/lib/5.8.1/i686-linux /opt/perl-5.8.1/lib/5.8.1 /opt/perl-5.8.1/lib/site_perl/5.8.1/i686-linux /opt/perl-5.8.1/lib/site_perl/5.8.1 /opt/perl-5.8.1/lib/site_perl . ___ My build steps: cd apache_1.3.29 ./configure --prefix=/home/httpd/httpd_perl --enable-module=proxy \ --enable-module=rewrite cd ../mod_perl-1.29 perl Makefile.PL APACHE_PREFIX=/home/httpd/httpd_perl \ APACHE_SRC=../apache_1.3.29/src NO_HTTPD=1 USE_APACI=1 \ EVERYTHING=1 PREP_HTTPD=1 APACI_ARGS='--disable-module=userdir \ --enable-module=proxy --enable-module=mod_rewrite' make After all of the cp lines, this happens: make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Apache' cp Apache.pm ../blib/lib/Apache.pm Manifying ../blib/man3/Apache.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Apache' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Connection' cp Connection.pm ../blib/lib/Apache/Connection.pm make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Connection' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Constants' cp Constants.pm ../blib/lib/Apache/Constants.pm Manifying ../blib/man3/Apache::Constants.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Constants' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/File' cp File.pm ../blib/lib/Apache/File.pm Manifying ../blib/man3/Apache::File.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/File' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Leak' cp Leak.pm ../blib/lib/Apache/Leak.pm /opt/perl-5.8.1/bin/perl /opt/perl-5.8.1/lib/5.8.1/ExtUtils/xsubpp -typemap /opt/perl-5.8.1/lib/5.8.1/ExtUtils/typemap -typemap typemap Leak.xs > Leak.xsc && mv Leak.xsc Leak.c cc -c -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" -fpic "-I/opt/perl-5.8.1/lib/5.8.1/i686-linux/CORE" Leak.c Running Mkbootstrap for Apache::Leak () chmod 644 Leak.bs rm -f ../blib/arch/auto/Apache/Leak/Leak.so LD_RUN_PATH="" cc -shared -L/usr/local/lib Leak.o -o ../blib/arch/auto/Apache/Leak/Leak.so chmod 755 ../blib/arch/auto/Apache/Leak/Leak.so cp Leak.bs ../blib/arch/auto/Apache/Leak/Leak.bs chmod 644 ../blib/arch/auto/Apache/Leak/Leak.bs Manifying ../blib/man3/Apache::Leak.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Leak' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Log' cp Log.pm ../blib/lib/Apache/Log.pm Manifying ../blib/man3/Apache::Log.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Log' make[1]: Entering directory `/home/bhoggard/src/htt
ANNOUNCE: HTML::Mason 1.24
This release contains a few small bug fixes: [ BUG FIXES ] - Two tests in 04-misc.t, #9 and #10, failed if Params::Validate 0.66+ was installed. This happened because an error message given by Params::Validate changed slightly, and was not a problem in the Mason core code. - The Component object method attr_if_exists returned 0 when the attribute didn't exist, instead of undef as is documented. Reported by Chris Reinhardt. - The HTML::Mason::Resolver::File glob_path method, which is used for the preloads feature, now uses File::Glob::bsd_glob when run with Perl 5.6.0+. This function properly handles spaces in filenames, which are legal on most systems, and common on Win32. Implemented by Autrijus Tang. - The Admin guide erroneously said that the default component root when running Mason outside a web environment was "/". It is the current working directory. Reported by Patrick Kane. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/ -- Forwarded message -- Date: Wed, 12 Nov 2003 18:59:37 +0100 From: PAUSE <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Dave Rolsky <[EMAIL PROTECTED]> Subject: CPAN Upload: D/DR/DROLSKY/HTML-Mason-1.24.tar.gz The uploaded file HTML-Mason-1.24.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DR/DROLSKY/HTML-Mason-1.24.tar.gz size: 327894 bytes md5: 99661ca087b26f560552280c73667e2a No action is required on your part Request entered by: DROLSKY (Dave Rolsky) Request entered on: Wed, 12 Nov 2003 17:58:47 GMT Request completed: Wed, 12 Nov 2003 17:59:36 GMT Thanks, -- paused, v460 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::DBI and MySQL warnings
On Tue, 2003-11-11 at 14:55, Perrin Harkins wrote:
> I think I'm going to end up just turning off
> warnings for that one line in Apache::DBI.
In case anyone is curious, this doesn't work. What does work is adding
"local $dbh->{'PrintError'} = 0;" right before that line in
Apache::DBI. A better solution though is calling $dbh->commit(), even
though it isn't needed on MyISAM tables. I'm leaving AutoCommit off
because in some of these operations I use InnoDB tables with
transactions.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] OutputFilter with UTF-8 characters
Ged Haywood wrote: Hi Stas, On Tue, 11 Nov 2003, Stas Bekman wrote: [snip] Who would think that a response handler: print while ; would affect the special vars in the filter called by print. Who indeed! [snip] So let's decide how do we act upon this: [snip] I'm not sure whether we should make a special case for $_ and localize it behind the scenes. I wonder if someone may find this to be a problem, if they try to use the non-licalized $_ for its side-effects. Many experienced Perl programmers will use special variables almost without thinking. Things like this are frightening, and it's why I'm sticking to mod_perl 1.x while continuing to read the experiences of other, more adventurous souls. I think it's necessary to make mod_perl behave like Perl as far as is possible. The chapter on mod_perl traps is big enough already, let's not let it get any bigger. mod_perl 2.0 does behave like Perl. It's just silly to say that someone is sticking with mod_perl 1.0 because they are frightened and frightening all the other people :) Frightening other people from using mp2 doesn't make mp2 any better. I think people on this list know pretty well, that if they have a problem we try to solve it right away, so it's not like you are on your own. I see no reason why people should be afraid of trying new things. If you take your mp1 code and run it on mp2 the discussed issue won't affect you at all. Only if you start using new features and write real filters (which are not available in mod_perl 1.0) you need to be aware that: print($_); is really: print(filter($_)); if you use an output filter, with all the usual pure perl consequences. For filter writers the advise would be to always localize any special Perl variables before using them. So if you are using a filter from CPAN chances are that it's well written, or if not point the author to the filters chapter which will soonish has this information on, so they can 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Running Mkbootstrap for Apache::Symbol - fails MP1.29
Barry Hoggard wrote: I'm trying to do a new install of apache and mod_perl on a Red Hat Linux box. I've build my own perl 5.8.1 in /opt/. This is the first time I've had a build fail in years. Red Hat Enterprise Linux ES release 2.1 (Panama) Apache 1.3.29 mod_perl 1.29 perl -V: Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration: Platform: osname=linux, osvers=2.4.9-e.27, archname=i686-linux uname='linux server1.tristanmedia.net 2.4.9-e.27 #1 tue aug 5 15:59:55 edt 2003 i686 unknown ' config_args='-Dprefix=/opt/perl-5.8.1 -des' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', optimize='-O2', cppflags='-fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm' ccversion='', gccversion='2.96 2731 (Red Hat Linux 7.2 2.96-118.7.2)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc libc=/lib/libc-2.2.4.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.2.4' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Oct 16 2003 12:06:43 %ENV: PERL5LIB=".:/home/bhoggard/dev/artcat/lib" @INC: . /home/bhoggard/dev/artcat/lib /opt/perl-5.8.1/lib/5.8.1/i686-linux /opt/perl-5.8.1/lib/5.8.1 /opt/perl-5.8.1/lib/site_perl/5.8.1/i686-linux /opt/perl-5.8.1/lib/site_perl/5.8.1 /opt/perl-5.8.1/lib/site_perl . ___ My build steps: cd apache_1.3.29 ./configure --prefix=/home/httpd/httpd_perl --enable-module=proxy \ --enable-module=rewrite cd ../mod_perl-1.29 perl Makefile.PL APACHE_PREFIX=/home/httpd/httpd_perl \ APACHE_SRC=../apache_1.3.29/src NO_HTTPD=1 USE_APACI=1 \ EVERYTHING=1 PREP_HTTPD=1 APACI_ARGS='--disable-module=userdir \ --enable-module=proxy --enable-module=mod_rewrite' make After all of the cp lines, this happens: make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Apache' cp Apache.pm ../blib/lib/Apache.pm Manifying ../blib/man3/Apache.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Apache' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Connection' cp Connection.pm ../blib/lib/Apache/Connection.pm make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Connection' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Constants' cp Constants.pm ../blib/lib/Apache/Constants.pm Manifying ../blib/man3/Apache::Constants.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Constants' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/File' cp File.pm ../blib/lib/Apache/File.pm Manifying ../blib/man3/Apache::File.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/File' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Leak' cp Leak.pm ../blib/lib/Apache/Leak.pm /opt/perl-5.8.1/bin/perl /opt/perl-5.8.1/lib/5.8.1/ExtUtils/xsubpp -typemap /opt/perl-5.8.1/lib/5.8.1/ExtUtils/typemap -typemap typemap Leak.xs > Leak.xsc && mv Leak.xsc Leak.c cc -c -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" -fpic "-I/opt/perl-5.8.1/lib/5.8.1/i686-linux/CORE" Leak.c Running Mkbootstrap for Apache::Leak () chmod 644 Leak.bs rm -f ../blib/arch/auto/Apache/Leak/Leak.so LD_RUN_PATH="" cc -shared -L/usr/local/lib Leak.o -o ../blib/arch/auto/Apache/Leak/Leak.so chmod 755 ../blib/arch/auto/Apache/Leak/Leak.so cp Leak.bs ../blib/arch/auto/Apache/Leak/Leak.bs chmod 644 ../blib/arch/auto/Apache/Leak/Leak.bs Manifying ../blib/man3/Apache::Leak.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Leak' make[1]: Entering directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Log' cp Log.pm ../blib/lib/Apache/Log.pm Manifying ../blib/man3/Apache::Log.3 make[1]: Leaving directory `/home/bhoggard/src/httpd_perl/mod_perl-1.29/Log' make[1]: Enteri
Re: mod_perl 1.99_11 errors with make test
Swen Schillig wrote: And again sorry, even this test is successful if the no_executable.pl file is really not executable !! Good to hear that. As I originally suggested it's possible that -O3 and gcc3.3.0 may have over-optimized something. So as I said before sorry for the hassle and thanks a lot for your support You welcome ;) __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: further benchmarks on different versions of Perl
Perrin Harkins wrote: [...] A) perl-5.006001 path= /usr/local/perl56/bin/perl cc = cc optimize= -O2 ccflags = -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 usemymalloc = n B) perl-5.008 path= /usr/local/perl580/bin/perl cc = cc optimize= -O3 ccflags = -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm usemymalloc = n BTW, notice that -02 and -03 aren't the same. As you will see from my followup next, this option can make quite a lot of difference. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: further benchmarks on different versions of Perl
Perrin Harkins wrote: On Mon, 2003-11-10 at 21:31, Stas Bekman wrote: Thanks Perrin for this comparison numbers, but I think you didn't provide enough build information. Default build opts vary from release to release and from OS to OS, you really need to show the whole perl -V to make these numbers more useful. Well, I'm not trying to do an analysis of compiler optimizations here. I built these the way I suspect almost everyone else does: all defaults. The main point was to see if there has been a degradation in performance since 5.6.1, since I have been hearing that a lot. The results show clearly enough to me that there has not been, and they agree with my previous benchmarks. They also show that if you don't need threads, it is very easy to build a Perl that performs significantly better than the one that comes with Red Hat 9, so it's worth doing if you are thinking about deploying a mod_perl app on Red Hat 9 and concerned about performance. Sure, Perrin, I understand your point. My goal is different, I'm not interested in defaults or perls shipped with distros. I'm interested in providing an advisory on how to build perl in such a way so that you will get the best performance. Though I think it's also compiled with ithreads, whereas all others are without, so it's not a fair comparison across different perl versions. That was actually the reason I included it: to get a sense of how much ithreads hurt performance. As you say though, the other options might be affecting it as well. OK, I did an extensive benchmarking, this time using the same stock perl 5.8.1, built in different ways. Here it is: OK, let's look at the same perl build differently and make comparisons. In the following comparison you will see the performance variations by as much as 50% without even starting to talk about enabling threads or not, removing threads will further improve the performance by some 20% and may be more. I've manually added -V:config_args, without which the benchmark is incomplete. A) perl-5.008001 (+shrplib, -ithreads, +perlio) path= /home/stas/perl/5.8.1/bin/perl cc = cc optimize= -g ccflags = -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm usemymalloc = n config_args = '-des -Dprefix=/home/stas/perl/5.8.1 -Doptimize=-g -Duseshrplib -Dusedevel'; B) perl-5.008001 (+shrplib, +ithreads, +perlio) path= /home/stas/perl/5.8.1-ithread/bin/perl cc = cc optimize= -g 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 usemymalloc = n config_args = '-des -Dprefix=/home/stas/perl/5.8.1-ithread -Dusethreads -Doptimize=-g -Duseshrplib -Dusedevel'; C) perl-5.008001 (-shrplib, +ithreads, +perlio) path= /home/stas/perl/5.8.1-ithread-nouseshrplib/bin/perl cc = cc optimize= -g 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 usemymalloc = n config_args = '-des -Dprefix=/home/stas/perl/5.8.1-ithread-nouseshrplib -Dusethreads -Doptimize=-g -Uuseshrplib -Dusedevel'; D) perl-5.008001 (+shrplib, -ithreads, +perlio) path= /home/stas/perl/5.8.1-nodebug/bin/perl5.8.1 cc = cc optimize= -O3 ccflags = -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm usemymalloc = n config_args='-des -Dprefix=/home/stas/perl/5.8.1-nodebug -Duseshrplib -Dusedevel' E) perl-5.008001 (-shrplib, -ithreads, -perlio) path= /home/stas/perl/5.8.1-nouseperlio/bin/perl cc = cc optimize= -g ccflags = -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm usemymalloc = n config_args = '-des -Dprefix=/home/stas/perl/5.8.1-nouseperlio -Doptimize=-g -Uuseperlio -Dusedevel' F) perl-5.008001 (+shrplib, +ithreads, +perlio) path= /usr/bin/perl cc = gcc optimize= -O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro ccflags = -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm usemymalloc = n config_args = '-des -Dinc_version_list=5.8.0/i386-linux-thread-multi 5.8.0 5.6.1 5.6.0 -Darchname=i386-linux -Dcc=gcc -Doptimize=-O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dman3ext=3pm -Dcf_by=MandrakeSoft -Dmyhostname=localhost [EMAIL PROTECTED] -Dd
Re: further benchmarks on different versions of Perl
John Day wrote: [...] Thanks for the comparisons. This is exactly what I think the bulk of users need to see. Like me, there must be thousands of users who have no idea what the compiler options mean and thus are not going to touch a single one! After your benchmark I can now relax and be comfortable that the Perl I compiled (my very first ever build of Perl!) is suited for my task. If you don't care much about performance, then yes, you can relax and just use whatever builds your favorite distro provides. If you after performance and before you spend any time optimizing your code, I'd humbly suggest that you should not relax, but learn about compiler options, run your own benchmarks on your own hardware that you will use in production and don't rely on any conclusions you've heard somewhere. p.s. The following chapters in "the practical mod_perl" book (http://modperlbook.org/toc.html) will give you an idea on how to boost the performance of your service without even touching your existing code: 7. Identifying Your Performance Problems 8. Choosing a Platform for the Best Performance 9. Essential Tools for Performance Tuning 11. Tuning Performance by Tweaking Apache's Configuration 12. Server Setup Strategies 14. Defensive Measures for Performance Enhancement 15. Improving Performance Through Build Options Notice that none of these chapters tells you what to do, they all suggest where things can be improved supported by benchmarks which may give a totally different result on your particular setup. They teach you 'How' and not 'What'. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: further benchmarks on different versions of Perl
On Wed, 2003-11-12 at 15:31, Stas Bekman wrote: > At the moment it looks like if you build your perl with -Uuseshrplib > -Uusethreads and don't enable debugging, and use a good selection of > optimization flags (like Mandrake 9.2's perl does), you will get the > best performance. Whee! Benchmarking is fun! Those are interesting numbers, but can this really be telling us that compiling with threads gives better performance? I guess we need to isolate that one option to get the answer. It was just pointed out to me by Sam Tregar that perlbench is heavy on math, and therefore not representative of what most of us do in our apps. It looks like you can replace the stock tests with your own, and I'd like to try it with a test that selects something from a database and runs it through a template. Sam also pointed out that the Intel compiler has a free evaluation download... When I get a little time,.I'll give these a shot. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Running Mkbootstrap for Apache::Symbol - fails MP1.29
Stas Bekman wrote:
It looks like you have a bad setting for PERL5LIB, it seems that it's
set to:
PERL5LIB = "PERL5LIB=/home/bhoggard/src/httpd_perl/mod_perl-1.29/lib .",
/home/bhoggard/dev/artcat/lib /opt/perl-5.8.1/lib/5.8.1/i686-linux
/opt/perl-5.8.1/lib/5.8.1
/opt/perl-5.8.1/lib/site_perl/5.8.1/i686-linux
/opt/perl-5.8.1/lib/site_perl/5.8.1 /opt/perl-5.8.1/lib/site_perl .)
at /opt/perl-5.8.1/lib/5.8.1/Pod/Parser.pm line 210
Compilation failed in require at /opt/perl-5.8.1/lib/5.8.1/Pod/Parser.pm
As it's chdir'ed to
/home/bhoggard/src/httpd_perl/mod_perl-1.29/Symbol
and it has '.' early in @INC, requiring Pod/Parser.pm, requires
Symbol.pm, which it finds in mod_perl-1.29/Symbol, but that's a wrong
Symbol.pm. That's why you get this error. You really want to get rid of
that misplaced '.' in your @INC. Notice that "." must be the last entry
in @INC, and you have it already.
Makefile.PL does:
$ENV{PERL5LIB} = join ':', "$PWD/lib", $ENV{PERL5LIB};
PERL5LIB => "PERL5LIB=$ENV{PERL5LIB}",
So it's your PERL5LIB setting that adds that '.' into the path. Fix it
and the problem will go away. To fix either unset it or do a local
override:
PERL5LIB="" perl Makefile.PL ...
Now can somebody explain to me why modperl has:
PERL5LIB => "PERL5LIB=$ENV{PERL5LIB}",
I can't see how is it going to work:
env PERL5LIB="PERL5LIB=/tmp" perl-5.8.1 -le 'print join "\n", @INC'
PERL5LIB=/tmp
/home/stas/perl/5.8.1/lib/5.8.1/i686-linux
/home/stas/perl/5.8.1/lib/5.8.1
/home/stas/perl/5.8.1/lib/site_perl/5.8.1/i686-linux
/home/stas/perl/5.8.1/lib/site_perl/5.8.1
/home/stas/perl/5.8.1/lib/site_perl
.
it doesn't really add /tmp to @INC. Do I miss somethng?
Ah. That was a stupid mistake that happened when I was working on installing an
autobundle file earlier in the day and having trouble getting perl -MCPAN to see it.
Thank you very much.
--
Barry Hoggard
Tristan Media LLC
e: [EMAIL PROTECTED]
w: www.tristanmedia.com
aim: hoggardb
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: further benchmarks on different versions of Perl
Perrin Harkins wrote: On Wed, 2003-11-12 at 15:31, Stas Bekman wrote: At the moment it looks like if you build your perl with -Uuseshrplib -Uusethreads and don't enable debugging, and use a good selection of optimization flags (like Mandrake 9.2's perl does), you will get the best performance. Whee! Benchmarking is fun! Those are interesting numbers, but can this really be telling us that compiling with threads gives better performance? I guess we need to isolate that one option to get the answer. No, -U means disable. -D means enable. So -Uuseshrplib and -Uusethreads means disabling threads and shared lib. It was just pointed out to me by Sam Tregar that perlbench is heavy on math, and therefore not representative of what most of us do in our apps. It looks like you can replace the stock tests with your own, and I'd like to try it with a test that selects something from a database and runs it through a template. Sam also pointed out that the Intel compiler has a free evaluation download... When I get a little time,.I'll give these a shot. That's a very good point, Perrin. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: further benchmarks on different versions of Perl
Stas Bekman wrote: [...] 2) D (+shrplib, -ithreads, +perlio, -debug) 128 A (+shrplib, -ithreads, +perlio, +debug) 100 D and A are the same builds, and similar to B&F the only difference is debugging enabled in A. As you can see with ithreads disabled enabled debugging affects the performance much less. Still it clearly shows that you don't want the debugging enabled on your production perl. What puzzles me greatly is that why F w/ ithreads outperforms D w/o ithreads. Go figure. I'm starting to be suspicios of making hard conclusions from running perlbench. The only possible reason I can think of is that: F: -O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro D: -O2 -finline-functions, -fweb, -funit-at-a-time, -ftracer, -funswitch-loops and -frename-registers F has better a better choice of optimizations. (D has -03 and I have expanded it according to the gcc manpage), e.g., D doesn't use the -mcpu optimization, which may be the crucial factor. Indeed, recompiling the stock perl 5.8.1 with Mandrake 9.2's optimization flags and not the defaults, speeds it up by about 12% (140 - 128, 97 - 100) (for the perlbench tests). Mandrake's threaded perl is just a tiny bit slower than my custom non-threaded perl build for this benchmark ;) A) perl-5.008001 path= /home/stas/perl/5.8.1-nodebug/bin/perl5.8.1 cc = cc optimize= -O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro ccflags = -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm usemymalloc = n B) perl-5.008001 path= /usr/bin/perl5.8.1 cc = gcc optimize= -O2 -fomit-frame-pointer -pipe -march=i586 -mcpu=pentiumpro ccflags = -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm usemymalloc = n A B arith/mixed 100 107 arith/trig 100 105 array/copy 100 104 array/foreach100 102 array/index 100 103 array/pop100 96 array/shift 100 93 array/sort-num 100 70 array/sort 100 81 call/0arg100 104 call/1arg100 100 call/2arg100 77 call/9arg100 105 call/empty 100 116 call/fib 100 98 call/method 100 108 call/wantarray 100 91 hash/copy100 94 hash/each100 76 hash/foreach-sort100 124 hash/foreach 100 105 hash/get 100 81 hash/set 100 89 loop/for-c 100 137 loop/for-range-const 100 107 loop/for-range 100 92 loop/getline 100 100 loop/while-my100 114 loop/while 100 105 re/const 100 107 re/w 100 66 startup/fewmod 100 83 startup/lotsofsub100 75 startup/noprog 100 76 string/base64100 101 string/htmlparser100 88 string/index-const 100 119 string/index-var 100 81 string/ipol 100 100 string/tr100 96 AVERAGE 100 97 __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[mp1] why PERL5LIB = "PERL5LIB=/.../mod_perl-1.29/lib"
Anybody has an idea why mp1 build does: PERL5LIB = "PERL5LIB=/path/to/mod_perl-1.29/lib", (see the top-level Makefile). I can't see how is it going to work: PERL5LIB="PERL5LIB=/tmp" perl-5.8.1 -le 'print join "\n", @INC' PERL5LIB=/tmp /home/stas/perl/5.8.1/lib/5.8.1/i686-linux /home/stas/perl/5.8.1/lib/5.8.1 /home/stas/perl/5.8.1/lib/site_perl/5.8.1/i686-linux /home/stas/perl/5.8.1/lib/site_perl/5.8.1 /home/stas/perl/5.8.1/lib/site_perl . it doesn't really add /tmp to @INC. Do I miss something? Looks like some ancient workaround for some problems... __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] why PERL5LIB = "PERL5LIB=/.../mod_perl-1.29/lib"
It is a very good question about the way that mod_perl-1 creates @INC. I would additionally point out the "." that in fact transforms into "/" for each mod_perl handler. I would appreciate if somebody can direct me to appropriate docs concerning the main idea under the hood to create @INC this way (and how it could be changed around the patch). It is closely related to one problem I had about a month ago with the "shaded" modules on one of my servers... Thanks, Slava On Wed, 2003-11-12 at 16:28, Stas Bekman wrote: > Anybody has an idea why mp1 build does: > > PERL5LIB = "PERL5LIB=/path/to/mod_perl-1.29/lib", > > (see the top-level Makefile). > > I can't see how is it going to work: > > PERL5LIB="PERL5LIB=/tmp" perl-5.8.1 -le 'print join "\n", @INC' > PERL5LIB=/tmp > /home/stas/perl/5.8.1/lib/5.8.1/i686-linux > /home/stas/perl/5.8.1/lib/5.8.1 > /home/stas/perl/5.8.1/lib/site_perl/5.8.1/i686-linux > /home/stas/perl/5.8.1/lib/site_perl/5.8.1 > /home/stas/perl/5.8.1/lib/site_perl > . > > it doesn't really add /tmp to @INC. Do I miss something? Looks like some > ancient workaround for some problems... > > __ > 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 > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
Marc Slagle wrote:
I don't have a test to reproduce the segfault, so I'm just shooting in the
dark based on the core trace that you've kindly provided. Please revert the
previous patch and try the new one:
We tried the new patch, but can still get the segfault. We wrote 3
modules that can reproduce the segfault on our system.
Here is a simple test that I was after. No XML, no XSLT, no extra modules
needed (i.e. no wasted time on developer's behalf). In the future please try
to come up with a similar test if possible.
package Server::Killer;
use 5.008;
use strict;
use Apache::Request;
use Apache::Constants qw(:common);
our $GlobalURI;
our $GlobalS;
sub handler
{
my $r=Apache::Request->new(shift);
$r->send_http_header;
$r->print("ok");
my $S=$r->param();
$GlobalS=$r->param();
my $Stuff=&readglobal;
return OK;
}
sub readglobal
{
my $Uri=$GlobalURI;
return $Uri;
}
1;
Same goes for the required config section, please always provide a minimal
config if possible. Here all was needed is:
Listen 127.0.0.1:8123
NameVirtualHost 127.0.0.1:8123
PerlTransHandlerServer::KillerTH
PerlHandler Server::Killer
Now it's easy to reproduce the segfault. Set MaxRequestPerChild 1 and run the
server with 'httpd -X', it crashes after the first request.
It crashes when it tries to destroy $GlobalS (during child_exit), which
contains a reference to an Apache::Table object which was already freed. Some
reference counting is going wrong. I'm still looking at 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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] why PERL5LIB = "PERL5LIB=/.../mod_perl-1.29/lib"
Slava Bizyayev wrote: It is a very good question about the way that mod_perl-1 creates @INC. I would additionally point out the "." that in fact transforms into "/" for each mod_perl handler. I would appreciate if somebody can direct me to appropriate docs concerning the main idea under the hood to create @INC this way (and how it could be changed around the patch). It is closely related to one problem I had about a month ago with the "shaded" modules on one of my servers... I'm afraid you are talking about a totally different thing. My question is about @INC during the mod_perl build. I think you are talking about the post-install thing, in which case please start a new thread and be more explicit of what is your problem, since I don't understand your description above. Thanks. On Wed, 2003-11-12 at 16:28, Stas Bekman wrote: Anybody has an idea why mp1 build does: PERL5LIB = "PERL5LIB=/path/to/mod_perl-1.29/lib", (see the top-level Makefile). I can't see how is it going to work: PERL5LIB="PERL5LIB=/tmp" perl-5.8.1 -le 'print join "\n", @INC' PERL5LIB=/tmp /home/stas/perl/5.8.1/lib/5.8.1/i686-linux /home/stas/perl/5.8.1/lib/5.8.1 /home/stas/perl/5.8.1/lib/site_perl/5.8.1/i686-linux /home/stas/perl/5.8.1/lib/site_perl/5.8.1 /home/stas/perl/5.8.1/lib/site_perl . it doesn't really add /tmp to @INC. Do I miss something? Looks like some ancient workaround for some problems... __ 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 -- __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] why PERL5LIB = "PERL5LIB=/.../mod_perl-1.29/lib"
On Wed, 2003-11-12 at 19:02, Stas Bekman wrote: > I'm afraid you are talking about a totally different thing. Yes, of-course. I'm sorry Stas, my head has been spinning a bit today... Slava -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
On Tue, 11 Nov 2003, Alexander Hartmaier wrote: > Hi! > > 1. Problem Description: > > My apache child crash with a segfault when I call a page > which generates a graph using the perl module GD::Graph. > > My system specs are: > > Fedora Core 1 > httpd-2.0.47 (from fedora, also tried with self-compiled 2.0.48) > mod_perl-1.99_11 (the final version, self-compiled) > embperl-2.0b10 (current cvs snapshot, self-compiled) > perl-5.8.1 (from fedora, also tried with self-compiled 5.8.2) > gd-2.0.15 (from fedora, also tried with self-compiled 2.0.15) > freetype-2.1.4 (from fedora, also tried with self-compiled 2.1.5) > > All perl modules are the newest version from CPAN. Do you know if an anlagous page outside of Embperl, using either ModPerl::Registry or a mod_perl content handler, also segfaults with GD::Graph? -- best regards, randy kobes -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: [...] It seems that your global $GlobalS var contains a reference to an Apache::Request table, but A-R object is not global, so when the scope of the handler is exited A-R object gets destroyed, leaving $GlobalS containting a pointer to a black hole. That black hole is req->parms in Request.xs in libapreq. Yup- the request pool's cleanup hook has already come through and reclaimed all those C data structures. Unfortunately the perl glue isn't aware that this happened. I think the basic assumption is that the request pool's lifetime must be longer than any perl scalar glued to a per-request struct. Of course, that assumption doesn't appear to be valid in this situation (a global Apache::Table object is alive, but the associated C table was freed). Not sure what to do about it right now. We have exactly the same issue with APR::Pool objects created via my $parent_pool = APR::Pool->new(); my $child_pool = $parent_pool->new(); if $parent_pool is destroyed first, it also eats the guts of its child, leaving $child_pool pointing to some invalid thing. The worst thing is that if some other pool gets allocated at the same pointer where child_pool point, it will be destroyed! Moreover, every time you say: my $parent2 = $child_pool->parent_get; you can't destroy $parent2, because it will nuke the guts of the parent and all the children. Therefore you can't just wrap and IV pointer into an SV and hand it to the perl side. Currently the solution that almost works is to introduce an internal reference counting, by incrementing the reference counting every time a new perl variable pointing to the pool is created, and decrementing when it's attempted to be destroyed. Only when the reference count reaches 0 we can destroy the actual pool. This reference counting is stored inside the C pool struct itself, via user data API. It's almost working. There is at least one problem with this approach that I forgot what it was, but I have a test that demonstrates it somewhere. The solution that I'm thinking to implement involves storing a real SV in the pool's user data and use Perl's reference counting. I think the same approach can be taken by A-R. Once I'll polish the solution with APR::Pool, we can apply it to A-R. In any case I've provided Marc with a workaround which should prevent segfaults, so there is no rush to fix it if you are busy with more urgent things. ALso, Marc, I'd suggest to rethink your coding techniques. Instead of using globals you should probably encapsulate all the data that you want to pass around into a single object and and pass it around, or using a Singleton object. Globals are not the best way to go in majority of cases. __ 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 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp1] why PERL5LIB = "PERL5LIB=/.../mod_perl-1.29/lib"
Stas Bekman wrote:
Anybody has an idea why mp1 build does:
PERL5LIB = "PERL5LIB=/path/to/mod_perl-1.29/lib",
(see the top-level Makefile).
I can't see how is it going to work:
Answering my own question, and the answer is trivial, this is just how we pass
PERL5LIB env var to the shell commands via Makefile, e.g.:
(cd $(APACHE_ROOT) && $(PERL5LIB) $(MAKE))
becomes:
(cd ../apache && PERL5LIB=/path/to/mod_perl-1.29/lib make)
however, for some reason .pm files during the modperl build see $ENV{PERL5LIB}
as "PERL5LIB=/path:/another/path" instead of "/path:/another/path" essentially
rendering this env var useless. I'm not sure why, may be MakeMaker kicks in
somewhere. I came up with a simple solution s/PERL5LIB/PERL5LIB_ENV/, anything
that's not PERL5LIB.
Index: Makefile.PL
===
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.218
diff -u -r1.218 Makefile.PL
--- Makefile.PL 9 Oct 2003 05:10:29 - 1.218
+++ Makefile.PL 13 Nov 2003 06:45:37 -
@@ -1291,7 +1291,7 @@
HTTPD => $TARGET,
PORT => $PORT,
PWD => $PWD,
-PERL5LIB => "PERL5LIB=$ENV{PERL5LIB}",
+PERL5LIB_ENV => "PERL5LIB_ENV=$ENV{PERL5LIB}",
SHRPENV => $Config{shrpenv},
CVSROOT => 'cvs.apache.org:/home/cvs',
},
@@ -1419,16 +1419,16 @@
(cd ./apaci && $(MAKE) distclean)
apxs_libperl:
- (cd ./apaci && $(PERL5LIB) $(MAKE))
+ (cd ./apaci && $(PERL5LIB_ENV) $(MAKE))
apxs_install: apxs_libperl
(cd ./apaci && $(MAKE) install;)
apache_httpd: $(APACHE_SRC)/Makefile.tmpl
- (cd $(APACHE_SRC) && $(PERL5LIB) $(SHRPENV) $(MAKE) CC="$(CC)";)
+ (cd $(APACHE_SRC) && $(PERL5LIB_ENV) $(SHRPENV) $(MAKE) CC="$(CC)";)
apaci_httpd:
- (cd $(APACHE_ROOT) && $(PERL5LIB) $(MAKE))
+ (cd $(APACHE_ROOT) && $(PERL5LIB_ENV) $(MAKE))
apaci_install:
(cd $(APACHE_ROOT) && $(MAKE) install)
Unless somebody objects to that change I'm going to commit it soonish.
__
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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
