bug report
-8<-- Start Bug Report 8<-- 1. Problem Description: Got the following output from 'make test': still waiting for server to warm up: . the server is down, giving up after 121 secs [ error] failed to start server! (please examine t/logs/error_log) ++ | Please file a bug report: http://perl.apache.org/bugs/ | ++ make: *** [run_tests] Error 1 A ps during that time showed three httpd processes running: nobody 29962 1 0 10:28 ?00:00:00 /opt/apache-2.2.0/bin/httpd d /opt/install/mod_perl-2.0.3/t -f /opt/install/mod_perl-2.0.3/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS nobody 29966 29962 0 10:28 ?00:00:00 /opt/apache-2.2.0/bin/httpd d /opt/install/mod_perl-2.0.3/t -f /opt/install/mod_perl-2.0.3/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS nobody 29967 29962 0 10:28 ?00:00:00 /opt/apache-2.2.0/bin/httpd d /opt/install/mod_perl-2.0.3/t -f /opt/install/mod_perl-2.0.3/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS Contents of t/logs/error_log: [Tue May 22 10:28:34 2007] [notice] Apache/2.2.0 (Unix) world domination series/2.0 mod_perl/2.0.3 Perl/v5.8.0 configured -- resuming normal operations [Tue May 22 10:28:34 2007] [info] Server built: May 22 2007 10:09:47 [Tue May 22 10:28:34 2007] [debug] prefork.c(991): AcceptMutex: sysvsem (default: sysvsem) 2. Used Components and their Configuration: *** mod_perl version 2.03 *** using /opt/install/mod_perl-2.0.3/lib/Apache2/BuildConfig.pm *** Makefile.PL options: MP_APR_LIB => aprext MP_APXS=> /opt/apache-2.2.0/bin/apxs MP_COMPAT_1X => 1 MP_GENERATE_XS => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 *** /opt/apache-2.2.0/bin/httpd -V Server version: Apache/2.2.0 Server built: May 22 2007 10:09:47 Server's Module Magic Number: 20051115:0 Architecture: 32-bit Server MPM: Prefork threaded: no forked: yes (variable process count) 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 DYNAMIC_MODULE_LIMIT=128 -D HTTPD_ROOT="/opt/apache-2.2.0" -D SUEXEC_BIN="/opt/apache-2.2.0/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" *** /usr/bin/ldd /opt/apache-2.2.0/bin/httpd libm.so.6 => /lib/tls/libm.so.6 (0x40023000) libaprutil-1.so.0 => /opt/apache-2.2.0/lib/libaprutil-1.so.0(0x40045000) libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40059000) libdb-4.0.so => /lib/libdb-4.0.so (0x4006) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x40108000) libapr-1.so.0 => /opt/apache-2.2.0/lib/libapr-1.so.0 (0x40128000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40149000) librt.so.1 => /lib/librt.so.1 (0x40156000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40168000) libdl.so.2 => /lib/libdl.so.2 (0x40195000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) *** (apr|apu)-config linking info -L/opt/apache-2.2.0/lib -laprutil-1 -lgdbm -ldb-4.0 -lexpat -L/opt/apache-2.2.0/lib -lapr-1 -lrt -lcrypt -lpthread -ldl *** /usr/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=linux, osvers=2.4.20-2.48smp, archname=i386-linux-thread-multi uname='linux str' config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -g -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef' useithreads=define usemultiplicity= useperlio= d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=un uselongdouble= usemymalloc=, bincompat5005=undef Compiler: cc='gcc', 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', optimize='', cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -
Re: bug report
LWP: 5.65 mod_perl : 1.9907 It looks like you have a very old version of mod_perl2 installed in addition to the one you just installed. I can't say whether that's the cause of the server not starting during 'make test', but it might help to remove it via rpm or whatever package manager you are using, and then reinstall 2.0.3.
Apxs not installed
Hello. While rebuilding our webserver, I am trying to install modperl 2.0.3 under Apache 2.0.52 on RHEL4. However, when I run 'perl Makefile.PL', it says it can't find apxs. I am quite sure it isn't installed -find doesn't find it, so it definitely doesn't exist under its own name- but if I understand things correctly, it is standard part of Apache. Am I missing something? Thanks. Martijn.
Re: Apxs not installed
Martijn wrote: > Hello. > > While rebuilding our webserver, I am trying to install modperl 2.0.3 > under Apache 2.0.52 on RHEL4. However, when I run 'perl Makefile.PL', > it says it can't find apxs. I am quite sure it isn't installed -find > doesn't find it, so it definitely doesn't exist under its own name- > but if I understand things correctly, it is standard part of Apache. > Am I missing something? That would be a question for a RH list, no? We don't even try to grok w.t.f. vendors do with their distributions. But just as an observation, apxs might have been chucked at an /sbin path, or renamed to disambiguate apxs-1.3 from apxs-2.0, or not be installed at all unless you install some httpd-devel package. This isn't really the right place to find out why redhat did what and why :) Bill
Re: Apxs not installed
On 5/23/07, Martijn <[EMAIL PROTECTED]> wrote: Hello. While rebuilding our webserver, I am trying to install modperl 2.0.3 under Apache 2.0.52 on RHEL4. However, when I run 'perl Makefile.PL', it says it can't find apxs. I am quite sure it isn't installed -find doesn't find it, so it definitely doesn't exist under its own name- but if I understand things correctly, it is standard part of Apache. Am I missing something? Are you trying to build a dynamic or static mod_perl? The instructions are pretty different but basically a dynamic server assumes you have apache already installed, in which case you would have apxs, and the static server does not. I've used the standard static server installation instructrions [1] on RHEL4 a number of times without problems. [1] http://perl.apache.org/docs/2.0/user/install/install.html#Static_mod_perl Thanks. Martijn. -- ~Tyler
segmentation fault.
Ok,
I have a system I converted from cgi to mod_perl.
We recently upgraded to mod_perl 2.0 and apache 2.2 on RHL5
I am having a problem. When I refresh a certain page 5 times or about (
it's completely random )
The page renders fine, but in my logs I see that an apache child died
because of a segmentation fault I believe
here is the error or I guess notice message.
[notice] child pid 25946 exit signal Segmentation fault (11) # ? do I
have to worry about this notice ? what we are building will be a live
system.
My question is why is it doing this? I have but try{} catch clauses on
the whole script and it has yielded me no errors
that I have detected on this before like somewhere deep in the code I am
missing a require().
Any ideas on how I could better trap a segmentation fault besides using
perl's try{} catch{} like catching it's signal?
Re: segmentation fault.
This happened to me once (actually many times, but I figured out my
approach on the first time), I could only figure out one way to
handle it, and its been the one thing I hate about perl ever since
(as I know there HAS to be a bettter way )
What I do:
package MyApp::Debug;
use constant DEBUG_FUNCTION_NAME => 1;
sub print_function_name {
# derive function name by looping caller, print to STDERR
}
sub print_caller_stack {
# print the entire caller stack. useful for odd debugging, print to
STDERR
}
package MyApp::JustAboutEverything;
sub render_page {
my ( $self )= @_;
MyApp::Debug::DEBUG_FUNCTION_NAME &&
MyApp::Debug::print_function_name();
}
sub another_function {
my ( $self )= @_;
MyApp::Debug::DEBUG_FUNCTION_NAME && MyApp::Debug::
print_function_name ();
}
its messy, because I need to put that damn DEBUG_FUNCTION_NAME in
every sub I want to act like this. if i were a better perl
programmer, I'd have take the time to figure out a better way to
overload how perl calls functions.
in any event, since DEBUG_FUNCTION_NAME is based a constant, the
lines are nicely optimized away in production code ( assuming you
turn that option off ). i think it ends upon average to making my
dev server run about 5% larger in memory use and about 5% slower in
exeuction too. but i just set DEBUG_FUNCTION_NAME to 0, and its gone.
my guess is that your error is causing an issue in some XS code or in
perl/apache iteself - so you're not going to get any error caught.
in the past, i've gotten those segfaults from:
reading a bad cookie ( libapreq2 .05, i think ) ( c error )
handling an upload via apache request2 ( c error )
having a bad tied session under Apache2::Session ( xs error )
some random apache2 error.
i don't know if any of that helps. good luck!
On May 23, 2007, at 3:49 PM, Tyler Bird wrote:
Ok,
I have a system I converted from cgi to mod_perl.
We recently upgraded to mod_perl 2.0 and apache 2.2 on RHL5
I am having a problem. When I refresh a certain page 5 times or
about ( it's completely random )
The page renders fine, but in my logs I see that an apache child
died because of a segmentation fault I believe
here is the error or I guess notice message.
[notice] child pid 25946 exit signal Segmentation fault (11) # ? do
I have to worry about this notice ? what we are building will be a
live system.
My question is why is it doing this? I have but try{} catch
clauses on the whole script and it has yielded me no errors
that I have detected on this before like somewhere deep in the code
I am missing a require().
Any ideas on how I could better trap a segmentation fault besides
using perl's try{} catch{} like catching it's signal?
Re: segmentation fault.
I've also gotten segfaults from reading a bad cookie. Another segfault problem I experienced was caused by using a lexical variable in a sub in a Registry script that was declared outside of the sub (specifically, it was a CGI.pm object). Those segfaults seemed to happen randomly only about 10 to 20 percent of the time. - Original Message - From: "Jonathan Vanasco" <[EMAIL PROTECTED]> To: "modperl mod_perl" Sent: Wednesday, May 23, 2007 4:49 PM Subject: Re: segmentation fault. (snip) in the past, i've gotten those segfaults from: reading a bad cookie ( libapreq2 .05, i think ) ( c error ) handling an upload via apache request2 ( c error ) having a bad tied session under Apache2::Session ( xs error ) some random apache2 error. i don't know if any of that helps. good luck!
sharing data structures between scripts (forms)
Hi, I've done a decent amount of work in a particular script which reads a (flatfile) database, builds some data structures (hashes of arrays of arrays) does some processing and spits out a form. I then want the user to choose some values on the form, submit it, then I would act upon that, ultimately updating the original data structure and writing out the mods - sounds pretty standard.. My question is, if I choose to handle the form submission (action="...") via a second (etc. etc.) script, how do I ensure my in-memory data structures will be available to that other script? I'm new to cgi/mod-perl, though I gather one could submit back to the same script - though this sounds like a pretty unscalable operation over the long haul, that is having *all* code in one script. Can someone point me down the right path? I have a feeling packages might have something to do with it - all my variables/structures are lexically scoped as is.. I apologize if this is not the right forum, but I am using mod_perl! Many thanks, Happy Star Wars 30th! -Mark
Re: sharing data structures between scripts (forms)
Mark- you can not ensure that in-memory structures will be processed by the same server/child, let alone be available to another script. You'll need to find an inter-process store for your persistent item if you're using something that provides for sessions ( ie Apache::Session ) you can just stuff the data in there. Otherwise Your best options are: an RDMBS a memcached store If you are only using 1 server , you could use a local storage option: some shared db store ( like berkley db , or a dbm ) a flat-file store a tied file one of the shared memory modules ( like FastMMap ) If you're only on 1 machine and can't use a session, i'd suggest using an rdbms like mysql, postgres or sqlite. the advantage is that you can run a quick cronjob that deletes keys that have been inactive for 30minutes or so. There is one ugly other option -- you could turn your data structures into a serialized form, and either enccypt or digitally sign them, and then have them sent back to the server and processed. you see that a lot in asp pages. its damn messy and causes a ton of excess bandwidth and processing power. pages with 2k of content quickly have 130k of session data in them.i'd highly recommend against it. On May 23, 2007, at 6:12 PM, Mark Henry wrote: Hi, I've done a decent amount of work in a particular script which reads a (flatfile) database, builds some data structures (hashes of arrays of arrays) does some processing and spits out a form. I then want the user to choose some values on the form, submit it, then I would act upon that, ultimately updating the original data structure and writing out the mods - sounds pretty standard.. My question is, if I choose to handle the form submission (action="...") via a second (etc. etc.) script, how do I ensure my in-memory data structures will be available to that other script? I'm new to cgi/mod-perl, though I gather one could submit back to the same script - though this sounds like a pretty unscalable operation over the long haul, that is having *all* code in one script. Can someone point me down the right path? I have a feeling packages might have something to do with it - all my variables/ structures are lexically scoped as is.. I apologize if this is not the right forum, but I am using mod_perl! Many thanks, Happy Star Wars 30th! -Mark // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | SyndiClick.com | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder | Web Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans | Collaborative Online Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
RE: mod_perl not loading into apache error.
On Tue, 22 May 2007, Sravan Garlapati wrote: Hi Friends, I am unable to install mod_perl-2.0.3 in my system(Windows). I am using apache version 2 Perl version 5.6.1. I have given from DOS command prompt. I put mod_perl-2.03 directory and its file in C:\Perl C:\Perl\mod_per-2.0.3> Perl makefile.pl APACHE_SRC=C:\Program Files\Apache Group\Apache2 When I run this its giving error. It require high version of perl >= 5.8 This means that you must have a perl version greater than or equal to 5.8 to build mod_perl. If you're starting from scratch, it'd be a good idea to use the latest perl. Also, as Perrin noted in another reply, unless you're familiar with compiling things on Windows, it's a lot easier to use binary versions of Perl: http://www.activestate.com/Products/ActivePerl/ Apache: http://httpd.apache.org/ and mod_perl: http://perl.apache.org/docs/2.0/os/win32/install.html -- best regards, Randy Kobes
Re: segmentation fault.
Tyler Bird wrote: > Ok, > > I have a system I converted from cgi to mod_perl. > > We recently upgraded to mod_perl 2.0 and apache 2.2 on RHL5 > > I am having a problem. When I refresh a certain page 5 times or about ( > it's completely random ) > > The page renders fine, but in my logs I see that an apache child died > because of a segmentation fault I believe > here is the error or I guess notice message. > > [notice] child pid 25946 exit signal Segmentation fault (11) # ? do I > have to worry about this notice ? what we are building will be a live > system. The best way to get an understanding of what's happening is to get a backtrace from a core dump. http://perl.apache.org/docs/2.0/devel/debug/c.html#Getting_the_core_File_Dumped Will tell you a lot about how to get to a usefull backtrace. Once you get something ouy of your crash, send it to this list and there might be a solution to your problem. Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5 http://gozer.ectoplasm.org/ m/gozer\@(apache|cpan|ectoplasm)\.org/ signature.asc Description: OpenPGP digital signature
