Re: [mp1] why PERL5LIB = "PERL5LIB=/.../mod_perl-1.29/lib"
Stas Bekman wrote:
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.
Bad patch, here is a fixed one:
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 07:16:02 -
@@ -1291,7 +1291,7 @@
HTTPD => $TARGET,
PORT => $PORT,
PWD => $PWD,
-PERL5LIB => "PERL5LIB=$ENV{PERL5LIB}",
+PERL5LIB_ENV => "PERL5LIB=$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)
__
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
apache::DBI handling extended DBI objects...
Hi, am running mod_perl 2 applications under this configuration: Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.8.0. DBI version 1.37 Apache::DBI version 0.92 Everything runs smoothly apart the DBI connections handled with Apache::DBI. I'm actually using Extropia ADT toolkit, so basically I'm storing under Apache::DBI not 'vanilla' DBI class objects but Extropia::Core::DataSource::DBI class objects (which directly extend DBI class). The error I catch is: [error] undef error - Undefined subroutine &Apache::DBI::db::quote called at /ADT/Modules/Extropia/Core/DataSource/DBI.pm Actually the Extropia::Core::DataSource::DBI module doesn't implement the quote method (being implemented in the base DBI class). The problem seems related with the caching/restoring mechanism, being almost the same using other mechanisms (Storable and Cache::Cache). Using such mechanisms the object I get back is truly blessed to the right class (Extropia::Core::DataSource::DBI) but still cannot anymore access base class not overloaded methods. No problems using base vanilla DBI objects. What's wrong ? Generally, are there known limitations caching/retrieving extended classes ? --Marco. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: mod_perl
I tried what you suggested, but I still have the same problem. The hend of the httpd.conf file contains: NameVirtualHost *:80 PerlRequire "/etc/httpd/conf/startup.pl" Include "/etc/httpd/conf/siteA" Include "/etc/httpd/conf/siteB" Include "/etc/httpd/conf/siteC" and /etc/httpd/conf/startup.pl contains #! /usr/bin/perl $ModPerl::RegistryCooker::NameWithVirtualHost = 1; And I restarted the httpd daemon. Peter Stas Bekman wrote: 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 -- 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] segfault when generating graphs with GD::Graph under Embperl
No I don't know...the embperl page calls another embperl page which generates the graph and returns the link to the graph as html tag Thanks, Alex Von: Randy Kobes <[EMAIL PROTECTED]> am 13.11.2003 05:48 An: Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED] Kopie:[EMAIL PROTECTED] Thema: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 *1* -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Newbie question...
Hi All. I've had a search through the archives, and can't seem to find anything relevant. Pointers would be welcome. I've got a Mandrake linux 8.1 system (yeah, old), from which I've removed the provided apache 1.3.20 setup. So, I'm starting from scratch. I downloaded apache 1.3.29, mod_perl 1.29, though I kept the perl 5.6.1 that I've already got. I've made apache, and gotten it running just fine. I shut it back down again. Now I try to build mod_perl. perl Makefile.PL EVERYTHING=1 make make test Hrm...okay...try it this way: perl Makefile.PL PERL_LOG=1 PERL_LOG_API=1 PERL_SSI=1 make make test I install AxKit on top of mod_perl, and then when the web server starts to load, it crashes with the message "Can't locate loadable object for Apache::Log in @INC...". I can find Log.pm in my library path, but no Log.so. Further, I can't see where Log.so is being built in mod_perl, as there's no .c file in the Log subdirectory. Clearly I'm doing something wrong here, but danged if I can tell what it is. Any clues? -Ken -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Newbie question...
Hi, I had completely the same problem myself, starting Apache with AxKit. http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/Problems_installing_mp1_and_apache-1.3.28_P73387/ Tom On Thu, 2003-11-13 at 13:45, Ken Corey wrote: > Hi All. > > I've had a search through the archives, and can't seem to find anything > relevant. Pointers would be welcome. > > I've got a Mandrake linux 8.1 system (yeah, old), from which I've > removed the provided apache 1.3.20 setup. > > So, I'm starting from scratch. I downloaded apache 1.3.29, mod_perl > 1.29, though I kept the perl 5.6.1 that I've already got. > > I've made apache, and gotten it running just fine. I shut it back down > again. > > Now I try to build mod_perl. > > perl Makefile.PL EVERYTHING=1 > > make > > make test > the web server won't start.> > > Hrm...okay...try it this way: > perl Makefile.PL PERL_LOG=1 PERL_LOG_API=1 PERL_SSI=1 > > make > > make test > > > I install AxKit on top of mod_perl, and then when the web server starts > to load, it crashes with the message "Can't locate loadable object for > Apache::Log in @INC...". > > I can find Log.pm in my library path, but no Log.so. Further, I can't > see where Log.so is being built in mod_perl, as there's no .c file in > the Log subdirectory. > > Clearly I'm doing something wrong here, but danged if I can tell what it > is. Any clues? > > -Ken -- \\\||/// \\ - - // ( @ @ ) -oOo--( )--oOo-- ___ ___tom schindl o __/ / / innovative medientechnik planung AG / /\/\/ / / /__/ / __mailto:[EMAIL PROTECTED] / / / / /_/ / / /___/http://www.impire.de / voice:+43(512)34193432,fax:+43(512)34193420 Eduard-Bodem-Gasse 6, A-6020 Innsbruck, Austria, Software Engineering -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Newbie question...
Thanks for writing, but using 'EVERYTHING=1' doesn't solve it for me. Even worse, with EVERYTHING=1, the install fails the tests, too (in addition to Apache::Log not being provided). -Ken On Thu, 2003-11-13 at 13:28, Thomas Schindl wrote: > I had completely the same problem myself, starting Apache with AxKit. > > http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/Problems_installing_mp1_and_apache-1.3.28_P73387/ > > Tom > > On Thu, 2003-11-13 at 13:45, Ken Corey wrote: > > Hi All. > > > > I've had a search through the archives, and can't seem to find anything > > relevant. Pointers would be welcome. > > > > I've got a Mandrake linux 8.1 system (yeah, old), from which I've > > removed the provided apache 1.3.20 setup. > > > > So, I'm starting from scratch. I downloaded apache 1.3.29, mod_perl > > 1.29, though I kept the perl 5.6.1 that I've already got. > > > > I've made apache, and gotten it running just fine. I shut it back down > > again. > > > > Now I try to build mod_perl. > > > > perl Makefile.PL EVERYTHING=1 > > > > make > > > > make test > > > the web server won't start.> > > > > Hrm...okay...try it this way: > > perl Makefile.PL PERL_LOG=1 PERL_LOG_API=1 PERL_SSI=1 > > > > make > > > > make test > > > > > > I install AxKit on top of mod_perl, and then when the web server starts > > to load, it crashes with the message "Can't locate loadable object for > > Apache::Log in @INC...". > > > > I can find Log.pm in my library path, but no Log.so. Further, I can't > > see where Log.so is being built in mod_perl, as there's no .c file in > > the Log subdirectory. > > > > Clearly I'm doing something wrong here, but danged if I can tell what it > > is. Any clues? > > > > -Ken -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[ANN] libapreq2-2.02-dev release candidate #1
2.02-dev will be a maintenance release to fix the reported segfaults with Apache::Cookie::new(). Please give this candidate a try at http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz == @section v2_02_dev Changes with libapreq2-2.02-dev - November 12, 2003 - Perl API [joes] Fix bogus pool/cookie initializers in Apache::Cookie::set_attr(), which caused Apache::Cookie::new to segfault. Bug first reported to modperl list by Wolfgang Kubens. Thanks! -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [MP1] Apache segfault after serving request
> 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. Thanks for all the help. We'll be looking into the Singleton object today. I agree that globals are not the best way to go. We will attempt to get our examples as small as possible if we need to post in the future. Marc Slagle Whapps, LLC -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
transaction Apache::DBI
Hi,
its been some times i'm reading, first time i'm writing :)
first let me present myself : Christophe, 33, working on a e-crm
application web based that deals with emails. This is app is written
mostly in Perl with some C++. We're using mp1, Apache 1.3, Embperl and
Postgres. The Perl libs are full object oriented.
Yes i know i'm a lucky guy :)
I need some explications on how to deals with transactions over
differents objects and method calls with mod_perl and ApacheDBI.
My problem is simple : i need to do some stuff that deals with many
method call on differents objects, each of these objects asking for
their own database object retrieve from ApacheDBI.
My question is : is it safe to use transactions of multiple objects,
doing a commit or rollback at the end as i'm sure i will stay in the
same interpreter space and that no other user can ask for the same
database handle to do some stuff while i'm working? or can ApacheDBI
give the same database handle to another user and mess with my
transaction?
btw, ApacheDBI is always returning me a handle with the default
parameters i used when issuing the connection ( {AutoCommit => 1} for
example), even if i changed the parameters with
local->{dbh}->{AutoCommit} = 0. Its seems i can't write in the cached
handle hash but what i only get is a local copy of this cached handle.
Am i right with this point? Is there another way to process? patch
ApacheDBI to write in the %Connected hash that deals with the cached
database handles? is this safe?
Thanks a lot with you answers, qui éclaireront ma lanterne as we say in
french.
Christophe
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Newbie question...
Ah, okay, found out a solution (but not the cause). Turns out that apache 1.3.29 ships with mod_perl 1.29 as an extension already. When I configured apache with this: ./configure \ --activate-module=src/modules/perl/libperl.a and then did a make && make install, the mod_perl installation was hunky dory, so *don't* download mod_perl and try to install it by hand, go with what's shipped with apache. Installing AxKit on top of that was a pain, because I also had to update the libxml2, libxslt and Sablotron libraries to get everything to compile correctly. However, once all of that was in place, AxKit works just as the website says it should. Hope this helps someone else. -Ken On Thu, 2003-11-13 at 13:49, Ken Corey wrote: > Thanks for writing, but using 'EVERYTHING=1' doesn't solve it for me. > Even worse, with EVERYTHING=1, the install fails the tests, too (in > addition to Apache::Log not being provided). > > -Ken > > On Thu, 2003-11-13 at 13:28, Thomas Schindl wrote: > > I had completely the same problem myself, starting Apache with AxKit. > > > > http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/Problems_installing_mp1_and_apache-1.3.28_P73387/ > > > > Tom > > > > On Thu, 2003-11-13 at 13:45, Ken Corey wrote: > > > Hi All. > > > > > > I've had a search through the archives, and can't seem to find anything > > > relevant. Pointers would be welcome. > > > > > > I've got a Mandrake linux 8.1 system (yeah, old), from which I've > > > removed the provided apache 1.3.20 setup. > > > > > > So, I'm starting from scratch. I downloaded apache 1.3.29, mod_perl > > > 1.29, though I kept the perl 5.6.1 that I've already got. > > > > > > I've made apache, and gotten it running just fine. I shut it back down > > > again. > > > > > > Now I try to build mod_perl. > > > > > > perl Makefile.PL EVERYTHING=1 > > > > > > make > > > > > > make test > > > > > the web server won't start.> > > > > > > Hrm...okay...try it this way: > > > perl Makefile.PL PERL_LOG=1 PERL_LOG_API=1 PERL_SSI=1 > > > > > > make > > > > > > make test > > > > > > > > > I install AxKit on top of mod_perl, and then when the web server starts > > > to load, it crashes with the message "Can't locate loadable object for > > > Apache::Log in @INC...". > > > > > > I can find Log.pm in my library path, but no Log.so. Further, I can't > > > see where Log.so is being built in mod_perl, as there's no .c file in > > > the Log subdirectory. > > > > > > Clearly I'm doing something wrong here, but danged if I can tell what it > > > is. Any clues? > > > > > > -Ken > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session permissions problem
Perrin Harkins writes: > Sorry if I came off overly critical. Many people have had problems > trying to use Mason with Apache::Session because of that article. This > is why on the Mason website the link to that article describes it as > outdated and steers people to newer documentation. (It probably should > also steer them to the new handler...) I've deactivated the link and pointed to the new handler. > By using Apache::Session::Flex. The configuration for > MasonX::Request::WithApacheSession also lets you do this. I was planning to use Flex too. But I came upon an email from Jeff http://marc.theaimsgroup.com/?l=apache-modperl&m=100283817811419&w=2 saying "Regarding Flex, nobody uses it. It is for debugging. If you have a particular variant of Flex that you use all the time (very likely), you can code up a 6-line module to make a real implementation like all the other session modules. Flex is for debugging, period." Is this outdated information? Is Flex now considered reasonable for production? (Not sure why it "for debugging" in the first place.) Is there any disadvantage to using it versus creating a custom session class? > In my opinion, the locking approach taken in Apache::Session is not a good one for > the average web site and you should simply turn it off by using the NullLocker. Yes, we're about to add a note to MasonX::Request::WithApacheHandler indicating as much. I have heard so many complaints about MySQL locking, and have encountered problems with it myself, that I have to wonder why it is still in the package at all (much less the default)? Is there any real way to use it successfully? If I can get it to fail out of the box with my two development server processes and a few hits an hour, how could it ever be trusted in production? > The latest Apache::Session on CPAN is version 1.54, released in October 2001. Perhaps this answers my previous question. :) Jon -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Newbie question...
Strange. I did completely the same last week on my mdk-9.2 installation and no problem. Have you really used the perl Makefile.PL call I did? The mod_perl Makefile.PL builds your apache automatically. I'd suggest removing all files and starting once more. Simply put your apache.tar.gz and mod_perl.tar.gz into the /tmp, unpackage both and make the Makefile.PL-call like its mentionned in INSTALL.Simple and include the option EVERYTHING=1. Tom Am Do, 2003-11-13 um 14.49 schrieb Ken Corey: > Thanks for writing, but using 'EVERYTHING=1' doesn't solve it for me. > Even worse, with EVERYTHING=1, the install fails the tests, too (in > addition to Apache::Log not being provided). > > -Ken > > On Thu, 2003-11-13 at 13:28, Thomas Schindl wrote: > > I had completely the same problem myself, starting Apache with AxKit. > > > > http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/Problems_installing_mp1_and_apache-1.3.28_P73387/ > > > > Tom > > > > On Thu, 2003-11-13 at 13:45, Ken Corey wrote: > > > Hi All. > > > > > > I've had a search through the archives, and can't seem to find anything > > > relevant. Pointers would be welcome. > > > > > > I've got a Mandrake linux 8.1 system (yeah, old), from which I've > > > removed the provided apache 1.3.20 setup. > > > > > > So, I'm starting from scratch. I downloaded apache 1.3.29, mod_perl > > > 1.29, though I kept the perl 5.6.1 that I've already got. > > > > > > I've made apache, and gotten it running just fine. I shut it back down > > > again. > > > > > > Now I try to build mod_perl. > > > > > > perl Makefile.PL EVERYTHING=1 > > > > > > make > > > > > > make test > > > > > the web server won't start.> > > > > > > Hrm...okay...try it this way: > > > perl Makefile.PL PERL_LOG=1 PERL_LOG_API=1 PERL_SSI=1 > > > > > > make > > > > > > make test > > > > > > > > > I install AxKit on top of mod_perl, and then when the web server starts > > > to load, it crashes with the message "Can't locate loadable object for > > > Apache::Log in @INC...". > > > > > > I can find Log.pm in my library path, but no Log.so. Further, I can't > > > see where Log.so is being built in mod_perl, as there's no .c file in > > > the Log subdirectory. > > > > > > Clearly I'm doing something wrong here, but danged if I can tell what it > > > is. Any clues? > > > > > > -Ken > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Newbie question...
No that's not right. At least the tar.gz I downloaded does ***NOT*** include any mod_perl, anybody could correct me here but I think it should not get to the archives that apache ships with mod_perl, and one does not have to download it. I think that your mod_perl is coming from all commands/compilations you tried before you simply forgot to supply activate-module, when reconfiguring apache after having built mod_perl. That's why i always let mod_perl-Makefile.PL build my apache. Tom Am Do, 2003-11-13 um 16.57 schrieb Ken Corey: > Ah, okay, found out a solution (but not the cause). > > Turns out that apache 1.3.29 ships with mod_perl 1.29 as an extension > already. > > When I configured apache with this: > > ./configure \ > --activate-module=src/modules/perl/libperl.a > > and then did a make && make install, the mod_perl installation was hunky > dory, so *don't* download mod_perl and try to install it by hand, go > with what's shipped with apache. > > Installing AxKit on top of that was a pain, because I also had to update > the libxml2, libxslt and Sablotron libraries to get everything to > compile correctly. > > However, once all of that was in place, AxKit works just as the website > says it should. > > Hope this helps someone else. > > -Ken > > > On Thu, 2003-11-13 at 13:49, Ken Corey wrote: > > Thanks for writing, but using 'EVERYTHING=1' doesn't solve it for me. > > Even worse, with EVERYTHING=1, the install fails the tests, too (in > > addition to Apache::Log not being provided). > > > > -Ken > > > > On Thu, 2003-11-13 at 13:28, Thomas Schindl wrote: > > > I had completely the same problem myself, starting Apache with AxKit. > > > > > > http://www.gossamer-threads.com/archive/mod_perl_C1/modperl_F7/Problems_installing_mp1_and_apache-1.3.28_P73387/ > > > > > > Tom > > > > > > On Thu, 2003-11-13 at 13:45, Ken Corey wrote: > > > > Hi All. > > > > > > > > I've had a search through the archives, and can't seem to find anything > > > > relevant. Pointers would be welcome. > > > > > > > > I've got a Mandrake linux 8.1 system (yeah, old), from which I've > > > > removed the provided apache 1.3.20 setup. > > > > > > > > So, I'm starting from scratch. I downloaded apache 1.3.29, mod_perl > > > > 1.29, though I kept the perl 5.6.1 that I've already got. > > > > > > > > I've made apache, and gotten it running just fine. I shut it back down > > > > again. > > > > > > > > Now I try to build mod_perl. > > > > > > > > perl Makefile.PL EVERYTHING=1 > > > > > > > > make > > > > > > > > make test > > > > > > > the web server won't start.> > > > > > > > > Hrm...okay...try it this way: > > > > perl Makefile.PL PERL_LOG=1 PERL_LOG_API=1 PERL_SSI=1 > > > > > > > > make > > > > > > > > make test > > > > > > > > > > > > I install AxKit on top of mod_perl, and then when the web server starts > > > > to load, it crashes with the message "Can't locate loadable object for > > > > Apache::Log in @INC...". > > > > > > > > I can find Log.pm in my library path, but no Log.so. Further, I can't > > > > see where Log.so is being built in mod_perl, as there's no .c file in > > > > the Log subdirectory. > > > > > > > > Clearly I'm doing something wrong here, but danged if I can tell what it > > > > is. Any clues? > > > > > > > > -Ken > > > -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
Thats the output I got: Program received signal SIGSEGV, Segmentation fault. 0x006bc582 in ?? () (gdb) (gdb) (gdb) BT #0 0x006bc582 in ?? () #1 0x00603c44 in ?? () #2 0x0106 in ?? () #3 0x005d4aa6 in ?? () #4 0x010a6940 in ?? () #5 0x0ab5c5bc in ?? () #6 0x41414141 in ?? () #7 0xbfe6e9a8 in ?? () #8 0x00fdebdd in ?? () #9 0x41414141 in ?? () #10 0x0a8be838 in ?? () #11 0x006039e4 in ?? () #12 0x0ab5c5bc in ?? () #13 0x0aa8d29c in ?? () #14 0xbfe6e9c8 in ?? () #15 0x005e2493 in ?? () #16 0x0ab5c5bc in ?? () #17 0x004c1410 in ?? () #18 0x0a8be838 in ?? () Is THIS really useful? Should I compile with debugging symbols? If yes what? apache or mod_perl? or embperl? Thanks, Alex Von: Gerald Richter <[EMAIL PROTECTED]> am 12.11.2003 07:55 An: Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED], [EMAIL PROTECTED] Kopie:[EMAIL PROTECTED] Thema:Re: [mp2] segfault when generating graphs with GD::Graph under Embperl > > 3. This is the core dump trace: (if you get a core dump): > > I tried but I can't catch any (I don't know and didn't manage to find out which > directory has to be writeable for the apache2 process under Embperl). > Please try to start your httpd under gdb: gdb /path/to/httpd set args -X -f /path/to/httpd.conf r Now request the page that segfaults, gdb should show the segfault, then type BT and you should get the backtrace. Gerald P.S. -X tell Apache to only start one process, which is better for debugging *2* -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
> > Should I compile with debugging symbols? Yes > If yes what? apache or mod_perl? or embperl? > mod_perl and Embperl For Embperl do perl Makefile.PL debug I don't have in mind the Makefile.PL flag for mod_perl, but you surly find it in the docs :-) Gerald > Thanks, Alex > > > > > Von: Gerald Richter <[EMAIL PROTECTED]> am 12.11.2003 07:55 > > > > An: Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED], > [EMAIL PROTECTED] > Kopie:[EMAIL PROTECTED] > > Thema:Re: [mp2] segfault when generating graphs with GD::Graph > under Embperl > > >> >> 3. This is the core dump trace: (if you get a core dump): >> >> I tried but I can't catch any (I don't know and didn't manage to >> find out which directory has to be writeable for the apache2 process >> under Embperl). >> > > > Please try to start your httpd under gdb: > > gdb /path/to/httpd > set args -X -f /path/to/httpd.conf > r > > Now request the page that segfaults, gdb should show the segfault, > then type > > BT > > and you should get the backtrace. > > Gerald > > P.S. -X tell Apache to only start one process, which is better for > debugging > > *2* -- Gerald Richter ecos electronic communication services gmbh IT-Securitylösungen * dynamische Webapplikationen * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 -- | | ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info | +- -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Antwort: Re: Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
compiled mod_perl and embperl with debugging option. output is this: # gdb /usr/sbin/httpd GNU gdb Red Hat Linux (5.3.90-0.20030710.41rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...(no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) set args -X (gdb) r Starting program: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x002a9582 in ?? () (gdb) BT #0 0x002a9582 in ?? () #1 0x009d5c44 in ?? () #2 0x0106 in ?? () #3 0x009a6aa6 in ?? () #4 0x005e3940 in ?? () #5 0x09f72cf4 in ?? () (gdb) Doesn't look like a better output than without debugging option... I never did this before. Is something missing? THX Alex Von: Gerald Richter <[EMAIL PROTECTED]> am 13.11.2003 15:44 An: Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED] Kopie:[EMAIL PROTECTED], [EMAIL PROTECTED] Thema:Re: Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl > > Should I compile with debugging symbols? Yes > If yes what? apache or mod_perl? or embperl? > mod_perl and Embperl For Embperl do perl Makefile.PL debug I don't have in mind the Makefile.PL flag for mod_perl, but you surly find it in the docs :-) Gerald > Thanks, Alex > > > > > Von: Gerald Richter <[EMAIL PROTECTED]> am 12.11.2003 07:55 > > > > An: Alexander Hartmaier/DEBIS/EDVG/[EMAIL PROTECTED], > [EMAIL PROTECTED] > Kopie:[EMAIL PROTECTED] > > Thema:Re: [mp2] segfault when generating graphs with GD::Graph > under Embperl > > >> >> 3. This is the core dump trace: (if you get a core dump): >> >> I tried but I can't catch any (I don't know and didn't manage to >> find out which directory has to be writeable for the apache2 process >> under Embperl). >> > > > Please try to start your httpd under gdb: > > gdb /path/to/httpd > set args -X -f /path/to/httpd.conf > r > > Now request the page that segfaults, gdb should show the segfault, > then type > > BT > > and you should get the backtrace. > > Gerald > > P.S. -X tell Apache to only start one process, which is better for > debugging > > *2* -- Gerald Richter ecos electronic communication services gmbh IT-Securitylösungen * dynamische Webapplikationen * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 -- | | ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info | +- *1* -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANN] libapreq2-2.02-dev release candidate #1
On Thu, 13 Nov 2003, Joe Schaefer wrote: > 2.02-dev will be a maintenance release to fix > the reported segfaults with Apache::Cookie::new(). > Please give this candidate a try at > > http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz > > == > @section v2_02_dev Changes with libapreq2-2.02-dev > > - November 12, 2003 - Perl API [joes] > > Fix bogus pool/cookie initializers in Apache::Cookie::set_attr(), > which caused Apache::Cookie::new to segfault. Bug > first reported to modperl list by Wolfgang Kubens. This builds and passes all tests (both C and perl) on Win32 - ActivePerl 807 (perl-5.8.1+) and Apache/2.0.48. An updated libapreq2 ppm package is available at http://theoryx5.uwinnipeg.ca/ppms/. -- best regards, randy -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: apache::DBI handling extended DBI objects...
Masetti Marco wrote: Hi, am running mod_perl 2 applications under this configuration: Apache/2.0.47 (Unix) mod_perl/1.99_09 Perl/v5.8.0. DBI version 1.37 Apache::DBI version 0.92 Everything runs smoothly apart the DBI connections handled with Apache::DBI. I'm actually using Extropia ADT toolkit, so basically I'm storing under Apache::DBI not 'vanilla' DBI class objects but Extropia::Core::DataSource::DBI class objects (which directly extend DBI class). The error I catch is: [error] undef error - Undefined subroutine &Apache::DBI::db::quote called at /ADT/Modules/Extropia/Core/DataSource/DBI.pm Actually the Extropia::Core::DataSource::DBI module doesn't implement the quote method (being implemented in the base DBI class). The problem seems related with the caching/restoring mechanism, being almost the same using other mechanisms (Storable and Cache::Cache). Using such mechanisms the object I get back is truly blessed to the right class (Extropia::Core::DataSource::DBI) but still cannot anymore access base class not overloaded methods. No problems using base vanilla DBI objects. What's wrong ? I doubt it's an Apache::DBI problem. Most likely something is borked in the sub-classing implementation, so you probably want to contact the author of the subclass. __ 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 tried what you suggested, but I still have the same problem.
The hend of the httpd.conf file contains:
NameVirtualHost *:80
PerlRequire "/etc/httpd/conf/startup.pl"
Include "/etc/httpd/conf/siteA"
Include "/etc/httpd/conf/siteB"
Include "/etc/httpd/conf/siteC"
and /etc/httpd/conf/startup.pl contains
#! /usr/bin/perl
$ModPerl::RegistryCooker::NameWithVirtualHost = 1;
And I restarted the httpd daemon.
Ah, sorry, actually $ModPerl::RegistryCooker::NameWithVirtualHost is 1 by
default. It doesn't work because ModPerl::Registry (I assume that this is the
class that you are using, since you didn't tell otherwise) uses a different
method to convert the location of the script into a package namespace:
package ModPerl::Registry;
...
my %aliases = (
...
namespace_from => 'namespace_from_filename',
...
So it uses a full path to the script.
So what you want to do is to subclass ModPerl::Registry and have the subclass
use the 'namespace_from_uri' method instead:
#file:ModPerl/RegistryURI.pm
#---
package ModPerl::RegistryURI;
use strict;
use warnings FATAL => 'all';
our $VERSION = '0.01';
use base qw(ModPerl::Registry);
sub handler : method {
my $class = (@_ >= 2) ? shift : __PACKAGE__;
my $r = shift;
return $class->new($r)->default_handler();
}
# a funky way to say:
# *namespace_from = \&ModPerl::RegistryCooker::namespace_from_uri;
my %aliases = (
namespace_from => 'ModPerl::RegistryCooker::namespace_from_uri',
);
__PACKAGE__->install_aliases(\%aliases);
1;
__END__
Now configure your server to use this new handler. For example:
Alias /perl /path/to/perl/scripts
SetHandler perl-script
PerlResponseHandler ModPerl::RegistryURI
Options +ExecCGI
#PerlOptions +ParseHeaders
__
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: apache::DBI handling extended DBI objects...
On Thu, 2003-11-13 at 13:19, Stas Bekman wrote: > I doubt it's an Apache::DBI problem. Most likely something is borked in the > sub-classing implementation, so you probably want to contact the author of the > subclass. I agree, it is probably a result of the fact that Apache::DBI does some strange subclassing tricks to override disconnect(). It doesn't actually do any kind of serialization, so it's not like Storable or Cache::Cache. If you can't get it to work and you don't mind changing your code to remove any disconnect() calls, you can use the DBI->connect_cached() method instead. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session permissions problem
On Thu, 2003-11-13 at 11:05, Jonathan Swartz wrote: > I've deactivated the link and pointed to the new handler. Thanks! > Is this outdated information? Is Flex now considered reasonable for > production? (Not sure why it "for debugging" in the first place.) Is there > any disadvantage to using it versus creating a custom session class? There is no reason to avoid Apache::Session::Flex. > I have heard so many complaints about MySQL locking, and have encountered > problems with it myself, that I have to wonder why it is still in the > package at all (much less the default)? I've never used it. People who really want mutual exclusion for their sessions would probably be better off using InnoDB tables and real transactions. My only large-scale use of Apache::Session was with Oracle, using standard transactions and no separate locking. > > The latest Apache::Session on CPAN is version 1.54, released in October > 2001. > > Perhaps this answers my previous question. :) Yes, it is far from actively maintained. I've been considering recommending that people use CGI::Session instead, since it is better documented and better maintained. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: transaction Apache::DBI
On Thu, 2003-11-13 at 10:32, Christophe Musielak wrote:
> My question is : is it safe to use transactions of multiple objects,
> doing a commit or rollback at the end as i'm sure i will stay in the
> same interpreter space and that no other user can ask for the same
> database handle to do some stuff while i'm working?
Yes. Database handles are not shared between interpreters.
> btw, ApacheDBI is always returning me a handle with the default
> parameters i used when issuing the connection ( {AutoCommit => 1} for
> example), even if i changed the parameters with
> local->{dbh}->{AutoCommit} = 0.
Hmmm... Was I talking to you about this on Perlmonks?
It sounds like maybe you don't understand what local() does, which is
not surprising since hardly anyone does. Any change you make with
local() only lasts for the current scope. If you change things without
local(), it will change the cached handle permanently.
- Perrin
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANN] libapreq2-2.02-dev release candidate #1
Joe Schaefer <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > 2.02-dev will be a maintenance release to fix > the reported segfaults with Apache::Cookie::new(). > Please give this candidate a try at > > http://httpd.apache.org/~joes/libapreq2-2.02_01-dev.tar.gz > > == > @section v2_02_dev Changes with libapreq2-2.02-dev > > - November 12, 2003 - Perl API [joes] > > Fix bogus pool/cookie initializers in Apache::Cookie::set_attr(), > which caused Apache::Cookie::new to segfault. Bug > first reported to modperl list by Wolfgang Kubens. > > > Thanks! Hi Joe, unfortunatelly i was not able to reply earlier. Thanks for your fix from this morning. Just for your info, after i applied your changes it seems to be work. The error does not occurs again. Nevertheless i will download the current release as soon as possible ;-) Thanks a lot. Wolfgang -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session permissions problem
> > > The latest Apache::Session on CPAN is version 1.54, released in October > > 2001. > > > > Perhaps this answers my previous question. :) > > Yes, it is far from actively maintained. I've been considering > recommending that people use CGI::Session instead, since it is better > documented and better maintained. Interesting! I'll take a look. Have you seen any comparisons of features anywhere? -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [ANN] libapreq2-2.02-dev release candidate #1
Wolfgang Kubens <[EMAIL PROTECTED]> writes: [...] > unfortunatelly i was not able to reply earlier. Thanks for your fix from > this morning. Just for your info, after i applied your changes it seems > to be work. The error does not occurs again. Great! However, after further testing, it appears that fix alone was insufficient. This release candidate is the best version available at the moment. > Nevertheless i will download the current release as soon as possible ;-) Outstanding- and thanks for being one of the early adopters of libapreq2! The best way for the package to improve now is for folks to start exercising the code. libapreq2 is a full order of magnitude more complex than libapreq1, which is why there are so many tests (over 100) already in the package. But there's plenty of room for more, especially wrt the perl modules. -- Joe Schaefer -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session permissions problem
On Thu, 2003-11-13 at 15:18, Jonathan Swartz wrote: > Interesting! I'll take a look. Have you seen any comparisons of features > anywhere? No, I don't think anyone has written up a comparison. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Apache::Registry install problem(cpan)
Title: Apache::Registry install problem(cpan) Hi all, I'm trying to install Apache::Registry either though cpan or just compiling I get the following errors when I do the make test(the perl Makefile.PL and make work fine): make[1]: Entering directory `/var/tmp/mod_perl-1.29/ModuleConfig' make[1]: Leaving directory `/var/tmp/mod_perl-1.29/ModuleConfig' make[1]: Entering directory `/var/tmp/mod_perl-1.29/PerlRunXS' make[1]: Leaving directory `/var/tmp/mod_perl-1.29/PerlRunXS' make[1]: Entering directory `/var/tmp/mod_perl-1.29/Server' make[1]: Leaving directory `/var/tmp/mod_perl-1.29/Server' make[1]: Entering directory `/var/tmp/mod_perl-1.29/Symbol' make[1]: Leaving directory `/var/tmp/mod_perl-1.29/Symbol' make[1]: Entering directory `/var/tmp/mod_perl-1.29/Table' make[1]: Leaving directory `/var/tmp/mod_perl-1.29/Table' make[1]: Entering directory `/var/tmp/mod_perl-1.29/URI' make[1]: Leaving directory `/var/tmp/mod_perl-1.29/URI' make[1]: Entering directory `/var/tmp/mod_perl-1.29/Util' make[1]: Leaving directory `/var/tmp/mod_perl-1.29/Util' /httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & /bin/sh: line 1: /httpd: No such file or directory httpd listening on port 8529 will write error_log to: t/logs/error_log letting apache warm up...\c done /usr/bin/perl t/TEST 0 still waiting for server to warm up...not ok server failed to start! (please examine t/logs/error_log) at t/TEST line 95. make: *** [run_tests] Error 111 === When I look at the t/logs/error_log there is no error_log file. I did a ls -al to the /root/.cpan/build/t directory and got: drwxr-xr-x 9 500 500 4096 Nov 13 14:22 . drwxr-xr-x 24 500 500 4096 Nov 13 14:22 .. drwxr-xr-x 2 500 500 4096 Nov 13 14:22 conf drwxr-xr-x 6 500 500 4096 Nov 13 14:22 docs -rw-r--r-- 1 root root 6444 Nov 13 14:22 httpd.conf drwxr-xr-x 2 500 500 4096 Oct 7 22:34 internal drwxrwxrwx 2 root root 4096 Nov 13 14:22 logs drwxr-xr-x 2 500 500 4096 Oct 7 22:34 modules drwxr-xr-x 3 500 500 4096 Nov 13 14:22 net -rw-r--r-- 1 500 500 1264 Dec 6 1997 README -rwxr-xr-x 1 root root 644 Nov 13 14:22 report -rw-r--r-- 1 500 500 628 Mar 24 2002 report.PL -rwxr-xr-x 1 root root 2099 Nov 13 14:22 TEST drwxr-xr-x 2 500 500 4096 Oct 7 22:34 TestDirectives -rw-r--r-- 1 500 500 2083 Jun 5 01:38 TEST.PL -rw-r--r-- 1 500 500 4369 Jul 12 17:35 TEST.win32 I noticed the 500 for the user id. Am I suppose to add a special userid and group id for this to work? I'm currently running RH9 with: httpd-2.0.40-21.5 perl-HTML-Tagset-3.03-28 perl-URI-1.21-7 perl-DBI-1.32-5 perl-DBD-MySQL-2.1021-3 perl-Digest-HMAC-1.01-11 perl-Filter-1.29-3 perl-5.8.0-88.3 perl-CPAN-1.61-88.3 perl-HTML-Parser-3.26-17 perl-libwww-perl-5.65-6 perl-Crypt-SSLeay-0.45-7 perl-Digest-SHA1-2.01-10 perl-Net-DNS-0.31-3 perl-CGI-2.81-88.3 Anyone who has any clue on how to solve this drop me a line…… Thanks….. Neil
Re: Apache::Session permissions problem
> On Thu, 2003-11-13 at 15:18, Jonathan Swartz wrote:
> > Interesting! I'll take a look. Have you seen any comparisons of features
> > anywhere?
>
> No, I don't think anyone has written up a comparison.
Well, at first glance it looks promising - lots of documentation and
examples, last release pretty recent - but then I took a look in
Apache::Session::MySQL and saw:
# stores the serialized data. Returns 1 for sucess, undef otherwise
sub store {
my ($self, $sid, $options, $data) = @_;
my $dbh = $self->MySQL_dbh($options);
my $lck_status = $dbh->selectrow_array(qq|SELECT GET_LOCK("$sid",
10)|);
unless ( $lck_status == 1 ) {
$self->error("Couldn't acquire lock on id '$sid'. Lock status:
$lck_status");
return undef;
}
...
return $dbh->selectrow_array(qq|SELECT RELEASE_LOCK("$sid")|);
}
So the default MySQL driver does locking just like Apache::Session, and
there's no built-in way to turn it locking. So it's possible that the same
locking problems that plague Apache::Session would happen in CGI::Session.
Argh!
Jon
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session permissions problem
On Thu, 2003-11-13 at 16:47, Jonathan Swartz wrote: > So the default MySQL driver does locking just like Apache::Session, and > there's no built-in way to turn it locking. So it's possible that the same > locking problems that plague Apache::Session would happen in CGI::Session. > Argh! So, basically you are left with using Apache::Session::Flex and its NullLocker class or making your own session module. You could also create a separate CGI::Session driver that doesn't have the locking in it. Apache::ASP takes a different approach, using MLDBM::Sync and relying on shared filesystems for clustered use. In general, putting more than a couple of scalars into a session is a mistake in nearly any web development environment, so making the session storage really amazing is probably not worth it. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Registry install problem(cpan)
Neil Lehouillier wrote: Hi all, I'm trying to install Apache::Registry either though cpan or just compiling I get the following errors when I do the make test(the perl Makefile.PL and make work fine): First of all, you aren't installing Apache::Registry, but mod_perl 1.x. Apache::Registry is just one of the modules that come with it. When you submit bug reports please follow the guidelines at http://perl.apache.org/bugs/ /httpd -f `pwd`/t/conf/httpd.conf -X -d `pwd`/t & /bin/sh: line 1: /httpd: No such file or directory it creates a symlink to the real httpd, and it should be ./httpd not /httpd. Since you didn't submit a proper bug report I can't tell what the problem is. We need at least to see what arguments did you pass to 'perl Makefile.PL' or what did you answer to the interactive questions via CPAN.pm. Most likely you gave it the wrong information about the location of httpd. Please spend some time reading: http://perl.apache.org/docs/1.0/guide/getwet.html#Building_mod_perl http://perl.apache.org/docs/1.0/guide/install.html before you try it again. Thanks. __ 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: Apache::Session permissions problem
> On Thu, 2003-11-13 at 16:47, Jonathan Swartz wrote: > > So the default MySQL driver does locking just like Apache::Session, and > > there's no built-in way to turn it locking. So it's possible that the same > > locking problems that plague Apache::Session would happen in CGI::Session. > > Argh! > > So, basically you are left with using Apache::Session::Flex and its > NullLocker class or making your own session module. You could also > create a separate CGI::Session driver that doesn't have the locking in > it. Sure, either of these things are easy to do once you know about them. My particular goal is finding a standard session mechanism for the Mason user community that's functional out of the box, well supported, and minimally confusing. Dave's MasonX::Request::WithApacheSession does go a long way towards this goal, but you still have to know about the various Apache::Session pitfalls. For now, I guess we focus on improving our documentation to help users avoid as many of these pitfalls as possible. Jon -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
ENV clean hash previous problem response
I did post a question but i did not recognize the answer (due to "my"
spam???).
Looking through google i've found that someone has answered me, asking for
more details.
Here there are:
mod_perl 2.0 (1.999??) and perl 5.81
My problem (comproved today) is that %ENV hash is not reseted on each new
request. As i use the HTTP_COOKIE to identify the users identity, it happens
that after i log in one PC with my id-pass, looking (just after) at other pc
i can see as if i was me (but in other pc).
Reloading the page returns things to normality, but it is very annoying.
My loved person-who-has-answered has said maybe the use of global variables
are the responsibles. Here is the (simplified) code, you can see that ref
hash is reseted before ... now i'm thinking ... i am reseting the var, yes,
but i'm not reseting the refs copy, so it is maintaing the old value ... i
now really think this is the mistake, i put (anyway) the code, but i will
test this.
As this question maybe is already solved, i ask two more questions:
Is $r->subprocess_env->clear; needed in mod_perl 2 ??
Is there any way to acced to HTTP_COOKIE without the ENV hash? throw $r for
example?
$info = $Generic -> info;
...
sub info {
my $info = {};
no warnings;
$info->{cookie} = $ENV{HTTP_COOKIE};
return $info;
}
What i'm going to do
my $info = {};
$Generic-> info($info);
...
sub info {
my ($info) =@_;
no warnings;
$info->{cookie} = $ENV{HTTP_COOKIE};
}
gerard uolaquetalestem wrote:
> Hi to comunity, i'm developing some scripts (handlers) that need (or
that's
> what i think) to fill the ENV hash, so i can take the cookie data.
Which mod_perl version are using? Always include at least that information
in
your questions.
Can we summarize your problem as %ENV getting a sticky value of the
previously
set HTTP_COOKIE value? It's supposed to be reset on each new request.
It's more likely that you have used some global variables and haven't
initialized them, so they persist across the requests. If you can show a
*short* code sample you are having a problem with, it'll be easier for us to
understand what your problem is.
__
Stas Bekman JAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas at stason.org 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
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: ENV clean hash previous problem response
SUCH SANMARTÍN, GERARD wrote:
I did post a question but i did not recognize the answer (due to "my"
spam???).
Looking through google i've found that someone has answered me, asking for
more details.
Here there are:
mod_perl 2.0 (1.999??) and perl 5.81
Sorry, please see what do we need you to tell us here:
http://perl.apache.org/bugs/
Is $r->subprocess_env->clear; needed in mod_perl 2 ??
it hasn't changed from mod_perl 1 I believe
Is there any way to acced to HTTP_COOKIE without the ENV hash? throw $r for
example?
You can access any HTTP headers via $r->headers_in
$r->headers_in->get('HTTP_COOKIE') or whatever header your client is setting
('COOKIE'?)
__
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: Antwort: Re: Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
> Program received signal SIGSEGV, Segmentation fault. > 0x002a9582 in ?? () > (gdb) BT > #0 0x002a9582 in ?? () > #1 0x009d5c44 in ?? () > #2 0x0106 in ?? () > #3 0x009a6aa6 in ?? () > #4 0x005e3940 in ?? () > #5 0x09f72cf4 in ?? () > (gdb) > > Doesn't look like a better output than without debugging option... > I never did this before. Is something missing? > It looks like the programm is jumping to some location with doesn't contain any real code. This is normaly a result of a memory corruption that is happeing earlier and very hard to track down. The best would be to create a very simple test case and reduce complexity of your pages to narrow down the reason. You should test it with a simple Embperl and with a simple Apache::Registry file, so we might know if it is an Embperl or mod_perl problem. Gerald -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Antwort: Re: Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
Gerald Richter wrote: Program received signal SIGSEGV, Segmentation fault. 0x002a9582 in ?? () (gdb) BT #0 0x002a9582 in ?? () #1 0x009d5c44 in ?? () #2 0x0106 in ?? () #3 0x009a6aa6 in ?? () #4 0x005e3940 in ?? () #5 0x09f72cf4 in ?? () (gdb) Doesn't look like a better output than without debugging option... I never did this before. Is something missing? It looks like the programm is jumping to some location with doesn't contain any real code. This is normaly a result of a memory corruption that is happeing earlier and very hard to track down. There is an easy way to work around it. Run the program under gdb and it'll remember the trace even the memory (frames) gets corrupted. gdb /path/to/httpd gdb> run -X issue a request here and gdb will tell you that you've got a segfault bt will give you the trace. Alex, I'd too suggest that you try to eliminate embperl and see if you can get the same problem with a plain mod_perl script/handler just like Gerald has suggested. __ 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: Antwort: Re: Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
Hi Stas, > There is an easy way to work around it. Run the program under gdb and > it'll remember the trace even the memory (frames) gets corrupted. > > gdb /path/to/httpd > gdb> run -X > issue a request here and gdb will tell you that you've got a segfault > bt > will give you the trace. > This is excatly what we have done and which gives the above trace with does not contain any usefull informations ... Gerald -- Gerald Richter ecos electronic communication services gmbh IT-Securitylösungen * dynamische Webapplikationen * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice: +49 6133 939-122 WWW:http://www.ecos.de/ Fax: +49 6133 939-333 -- | | ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info | +- -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Antwort: Re: Antwort: Re: [mp2] segfault when generating graphs with GD::Graph under Embperl
Gerald Richter wrote: Hi Stas, There is an easy way to work around it. Run the program under gdb and it'll remember the trace even the memory (frames) gets corrupted. gdb /path/to/httpd gdb> run -X issue a request here and gdb will tell you that you've got a segfault bt will give you the trace. This is excatly what we have done and which gives the above trace with does not contain any usefull informations ... Sorry, Gerald. I've missed that detail then. In which case you need to try to manually step through guessing some breakpoints where things could go wrong. __ 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
