Re: help with mod_perl: undefined symbol: Perl_sv_2pv_flags
Hi Peter, you fail to give us the information required to solve your problem. Please see: http://perl.apache.org/docs/2.0/user/help/help.html#Reporting_Problems Tom peter pilsl wrote: I use mod_perl for a very long time already. Now I installed apache2.0.52 and took the chance to install a new mod_perl as well. First I tried the new 2.0RC3, then I tried 1.99.17, then 1.99.16 und finally 1.99.14 and all failed with the very same problem. Apache could not start up due to the following error: Cannot load /usr/local/apache2/modules/mod_perl.so into server: /usr/local/apache2/modules/mod_perl.so: undefined symbol: Perl_sv_2pv_flags I then copied my old 1.99.08-module (that was compiled with apache 2.0.48) to the modules-folder and everything seems to work fine now. But I want to use a newer version. Where should I start to look for my problem? is it a perl-problem? a apache-problem? a mod_perl-problem? I buildt mod_perl with: perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=/usr/local/apache2 thnx, peter
help with mod_perl: undefined symbol: Perl_sv_2pv_flags (full system report this time)
My first problem-report yesterday did not include much useful information. Thnx to Tom for pointing this out, so here it comes again with much more information from t/REPORT What suprised me is that at the end it states that there are several versions of mod_perl-modules installed. Is this a possible cause of my problem? thnx, peter 1. Problem Description: apache cannot start due to the following error: Cannot load /usr/local/apache2/modules/mod_perl.so into server: /usr/local/apache2/modules/mod_perl.so: undefined symbol Perl_sv_2pv_flags I tried with several versions from 1.99_14 to 1.99_17 Finally I reverted to my old mod_perl 1.99_08 -module compiled for 2.0.48 and put it to the modules-folder of my new 2.0.52 and things work fine, but I would prefer using a newer mod_perl-module 2. Used Components and their Configuration: *** mod_perl version 1.9916 *** using /usr/src/mod_perl-1.99_16/lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB = aprext MP_AP_PREFIX= /usr/local/apache2 MP_COMPAT_1X= 1 MP_GENERATE_XS = 1 MP_INST_APACHE2 = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /usr/local/apache2/bin/httpd -V Server version: Apache/2.0.52 Server built: Jan 19 2005 22:39:49 Server's Module Magic Number: 20020903:9 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_SYSVSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** (apr|apu)-config linking info -L/usr/local/apache2/lib -lapr-0 -lrt -lm -lcrypt -lnsl -lpthread -ldl -L/usr/local/apache2/lib -laprutil-0 -lgdbm -ldb-4.1 -lexpat *** /usr/local/bin/perl -V Summary of my perl5 (revision 5 version 8 subversion 5) configuration: Platform: osname=linux, osvers=2.4.24, archname=i686-linux uname='linux goldfisch.at 2.4.24 #9 wed mar 10 22:29:04 cet 2004 i686 unknown ' config_args='-de' 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 -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='2.96 2731 (Mandrake Linux 8.1 2.96-0.62mdk)', 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 -lndbm -lgdbm -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='-Wl,-E' 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 Sep 21 2004 11:47:55 %ENV: PERL_LWP_USE_HTTP_10=1 @INC: /usr/local/lib/perl5/5.8.5/i686-linux /usr/local/lib/perl5/5.8.5 /usr/local/lib/perl5/site_perl/5.8.5/i686-linux /usr/local/lib/perl5/site_perl/5.8.5 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl . *** Packages of interest status: Apache::Request: - CGI: 3.05 LWP: - mod_perl : 1.9908, 1.9914, 1.9916 This report was generated by t/REPORT on Thu Jan 20 10:04:04 2005 GMT.
mod_perl/FreeBSD Bug
Hello,
We are using the latest version of Apache (1.3.33) and mod_perl (1.29)
running on FreeBSD 4.9. When mod_perl is compiled as a DSO the server
grows
by approximately 12MB every time it does a graceful restart. When it gets
greater than 512MB FreeBSD stops giving it more memory (this can be
changed
in the kernel) the server will die. I have heard of other people with this
problem and it seems to be widely known. In our environment this only
happens on the FreeBSD servers, Linux is unaffected
The advice appears to be either do a full restart or compile in mod_perl
with Apache. A full restart would inconvenience many users and is not
practical. Does anyone know of a fix?
We compiled in mod_perl with Apache which fixed the memory leak but
introduced a very strange bug. A hash was being corrupted, only some data
was being set when a package is preloaded. This does not happen when
compiled as a DSO. Again, Linux is unaffected by this bug even when
mod_perl is compiled in with Apache.
I produced a short test case to demonstrate this bug. It appears that on
FreeBSD when packages are preloaded they are compiled twice. This does not
happen on Linux. We found this out by tie()ing a hash and writing every
access to a file. The test case sets two keys on a hash. When this is
preloaded on Linux the following happens to the hash on Apache start up:
Hash is created
Key 'a' is set
Key 'b' is set
and the hash is destroyed when Apache exits. I would expect this
behaviour.
On FreeBSD when compiled as a DSO the following happens:
Hash 1 is created
Key 'a' is set on hash 1
Key 'b' is set hash 1
Hash 1 is destroyed
Hash 2 is created
Key 'a' is set on hash 2
Key 'b' is set hash 2
Hash 1 and 2 are the same declared hash but different instances. As you
can
see it appears the code has been compiled twice but it runs as normal.
When
the same code is preloaded on a build where mod_perl is compiled into
Apache the following happens which demonstrates the bug:
Hash 1 is created
Key 'a' is set on hash 1
Key 'b' is set hash 1
Key 'a' is set on hash 1
Hash 2 is created
Hash 1 is destroyed
Key 'b' is set hash 2
Therefore the hash is only populated with 'b' as 'a' has been set twice on
the first instance of the hash. This does not happen if the
PerlFreshRestart is not defined in the Apache configuration, but this
means
we cannot update code with a graceful restart. Does anyone know of a fix?
The code for the test case is defined below. The bug only appears when the
Test::A and Test::B packages are defined in separate files. If they are
defined in-line, even in a BEGIN block the bug does not appear. The bug
also disappears when the hash is defined as a package variable 'our'
rather
than a lexically scoped variable 'my'. Note the 'use Test::A' and 'use
Test::B' must come after the 'set' subroutine as they call it.
We are therefore in a situation where on FreeBSD if we use mod_perl as a
DSO the server crashes and if we compile it in with Apache data gets
corrupted. We have tested this on vanilla and FreeBSD ports builds. None
of
these bugs are present on Linux.
So can anyone give us advice on fixing the memory leak and/or fixing the
data corruption?
Any suggestions are gratefully received.
Kind regards,
Tim
Test code (Test.pm, Test/A.pm, Test/B.pm)
Test.pm
--
package Test;
use strict;
use warnings;
use Data::Dumper;
my %hash;
sub set {
$hash{$_[1]} = '';
};
sub handler {
print Dumper \%hash;
}
use Test::A;
use Test::B;
1;
--
Test/A.pm
--
package Test::A;
use strict;
use warnings;
Test-set('a');
1;
--
Test/B.pm
--
package Test::B;
use strict;
use warnings;
Test-set('b');
1;
--
--
Timothy Coggins
Perl Programmer, Sophos
Tel: 01235 559933
Web: www.sophos.com
Sophos - protecting businesses against viruses and spam
Re: help with mod_perl: undefined symbol: Perl_sv_2pv_flags (full system report this time)
I could swear that there is something left off from your last installations see the different perl installations found on your system. Still this is only a wild guess you have to wait for the gurus around here. As a sidenote I always install/compile my own perl and for my apache you could also do that because you don't run the latest stable release which is 5.8.6. Compiling perl is really not that tricky, for most things you can use the default values but be aware when you want to run mod-perl in a threaded-mpm to compile this in if you run prefork leave it out because a thread-save perl is slower. Be aware to install you perl in a different location than /usr/local because then you'll wipe out your old install. Tom peter pilsl wrote: *** Packages of interest status: Apache::Request: - CGI: 3.05 LWP: - mod_perl : 1.9908, 1.9914, 1.9916 This report was generated by t/REPORT on Thu Jan 20 10:04:04 2005 GMT.
RE: Problem on RedHat Enterprise 3.0
It's the whole sticking with the vendor for support thing. We have a support contract with RedHat and every time I've gone away from any stock RPM they always come back with well... You know you... Blah blah blah.. Unfortunately, I'm stuck and am just following orders.. get that version working. Thanks for all the suggestions everyone. Just got back in from the flu and will try to digest all this and see what I can come up with for a solution. It's been a year since I worked with mod_perl so there's a slight learning curve to go through again. -Original Message- From: Perrin Harkins [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 8:15 PM To: Young, Darren Cc: modperl@perl.apache.org Subject: Re: Problem on RedHat Enterprise 3.0 Young, Darren wrote: I installed their (RedHat) mod_perl rpm (1.99_09) I understand that you're trying to stick with your vendor's packaging system, but that's a really old version of mod_perl 2. It was released about two years ago, and there have been two years worth of bug fixes since then. It's hard for the people on the list to effectively support users who are running what is essentially an alpha version of mod_perl 2. Please consider building your own RPM of the most recent version, or bugging Red Hat to package something more up-to-date. [Wed Jan 19 14:34:18 2005] [error] [client 67.184.77.67] Can't locate object method print via package Apache::RequestRec at /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/Apache/Status .pm line 144.! Can you tell us what version of Apache::Status that is? I'm not sure there even was an Apache::Status port for mod_perl 2 at the time. Could this be left over from a mod_perl 1 installation you have on that box? - Perrin
Re: [mp2] reliable methods to prevent handlers from repeating
instead of looping around try $r-main-notes or $r-prev-notes hm, that loop should eventually hit all requests in the chain though, no? also, the first hit to that handler could in fact be a subrequest, so $r-main-notes may never be set. i do admit i'm cargo culting a little bit by looping over the request chain. my understanding is the aforementioned statement equates to return declined if you find a true value in a specific note in this request or any one that has occurred since the main request.. if that's not the case, what am i missing? what technique would you use if you had to have a handler work exactly once, even though it may never be invoked as an initial request?
Re: [mp2] reliable methods to prevent handlers from repeating
what technique would you use if you had to have a handler work
exactly once, even though it may never be invoked as an initial
request?
if you're in prefork, off the top of my head I might set a perl global and
then reset it using a cleanup handler. something like
$My::Foo::seen++;
$r-register_cleanup(sub { undef $My::Foo::seen });
so, again in prefork only, at the start of any request $My::Foo::seen should
be false. all bets are off if you're using threads.
--Geoff
Re: [mp2] reliable methods to prevent handlers from repeating
On Thu, Jan 20, 2005 at 02:32:59PM -0800, Philippe M. Chiasson wrote:
Dorian Taylor wrote:
suppose i wanted the same logic as:
return Apache::DECLINED unless $r-is_initial_req;
except that sometimes it may be necessary to serve for a subrequest,
just not more than once. the construct i tried is:
for (my $pr = $r; $pr; $pr = $pr-prev) {
if ($pr-notes-get(__PACKAGE__ . '::SEEN')) {
$r-log-debug(We've been seen already.);
return Apache::DECLINED;
}
}
$r-notes-set(__PACKAGE__ . '::SEEN', 1);
That's because you are setting that SEEN flag in the subrequest itself,
and that subrequest will most likely be short lived. Nobody will see that
flag, unless that subrequest fires off another subrequest of it's own.
that's exactly it. the subrequest does in fact launch subrequests
of its own. it's possible that hits to the uri handled by this
handler may come by way of a lookup_uri from another handler, so a
test to is_initial_req or is_main won't suffice. the desired effect
is this:
GET /foo [handled by mod_foo]
`- lookup_uri /somewhere/else [handled by this module]
`- lookup_uri /somewhere/else/again [same, but return declined]
exactly as if the first request to /somewhere/else was the main
request and there was a test against $r-is_main, but there's no
guarantee of that.
What you are trying to do is probably :
$r-main-notes-set(__PACKAGE__ . '::SEEN', 1);
And then your check becomes
$r-main-notes-get(__PACKAGE__ . '::SEEN');
Without a need to cycle over the requests list either.
if that was the case, couldn't i just test against $r-is_main?
if you had to deal with this scenario, what would you do?
cheers
.d
Re: [mp2] reliable methods to prevent handlers from repeating
what about unregistering the handler from the stack? is that possible? yes, but only if the phase you want to unregister isn't the same as the current phase # works, except during a PerlAuthenHandler $r-set_handlers(PerlAuthenHandler = []); just to clarify: what *are* $r-next/prev if not a way to access the requests that have happened since the main, or is it only those which have happened via internal_redirect? are the subrequests generated by lookup_uri exempt from the list? $r-is_initial_req() should return true only for the request that came from the browser. $r-is_main() should return true for the first in a series of (sub)requests, subrequests or otherwise. so, it returns true for the request that came from the browser, as well as any initiated from internal_redirect() $r-main returns the first $r in a series of (sub)requests, both those generated from internal_redirect as well as the initial request from the browser. if you had to deal with this scenario, what would you do? probably the globals trick I mentioned :) HTH --Geoff
RE: Problem on RedHat Enterprise 3.0
Just tried to install Bundle::Apache, it's asking for Apache source.. Also, it's pulling down mod_perl 1.29.. Isn't that older than the 1.99 I have? CPAN points to pair.com on that system. -Original Message- From: Jay Scherrer [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 19, 2005 5:01 PM To: modperl@perl.apache.org Subject: Re: Problem on RedHat Enterprise 3.0 Darren Young, Have you checked to see if Apache::RequestRec was installed? Try CPANing the installation of Bundle::Apache. It looks like your mod_perl is looking for the Lib ok but it's not installed. Jay Scherrer On Wednesday 19 January 2005 12:58 pm, Young, Darren wrote: Apache::RequestRec
Re: Problem on RedHat Enterprise 3.0
Young, Darren wrote: Is there a different way to CPAN the newer version? Perl -MCPAN -e 'install Bundle::Apache' gets the 1.29 stuff. I believe Perl -MCPAN -e 'install Bundle::Apache2' should get you latest version of mod_perl 2.0 (2.0_RC3 as of this writing). Yes, Apache 2.0.46 on RHEL. If I decide to go from source, I'm guessing I need to build a fresh Apache RPM, or at least have the source handy for the mod_perl build. For the mod_perl side, does the tarball include a way to build an RPM or is there somewhere else I should check? You should be able to get source RPM's (AKA SRPM) from the same source that you get your binary RPM's from. These will include, along with the source tarball and any necessary patches, a file with .spec extension (this file will normally end up in /usr/src/redhat/SPECS if you install the SRPM using rpm), which tells rpm how to build the binary RPM. For more information, take a look at http://www.rpm.org HTH, Ian
