RE: unable to compile mod_perl under perl 5.10.1
Hi Fred Thanks for the answer. getting correct -fPIC is probably the solution, but how? On perl 5.10.0 it turned up under config flags, but here it does not, but under cccdlflags in dynamic linking? There is probably some parsing in the Configure script that rearrange it. platform is CentOS 5.2 (latest patches) Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=linux, osvers=2.6.18-164.9.1.el5, archname=x86_64-linux-thread-multi uname='linux mortenb5.secana.local 2.6.18-164.9.1.el5 #1 smp tue dec 15 20:57:57 est 2009 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -A ccflags=-DPERL_USE_SAFE_PUTENV -Dusethreads -Dprefix=/opt/perl -Dinstallprefix=/opt/perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-46)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector' -Original Message- From: Fred Moyer [mailto:f...@redhotpenguin.com] Sent: 11. januar 2010 22:29 To: Morten Bjørnsvik Cc: mod_perl list Subject: Re: unable to compile perl under perl 5.10.1 Have you verified perl was actually compiled with fpic? perl -V On Mon, Jan 11, 2010 at 7:23 AM, Morten Bjørnsvik morten.bjorns...@experian-da.no wrote: Hi all I'm unable to compile mod_perl-2.0.x from svn(trunk 2.0.5-dev) or cpan(2.0.4) on perl 5.10.1, do anyone have some black belt options that make it works, I believed the -fPIC now is embedded in the -Dusethreads, because I see it appear lots of places in the perl compile output I've tried compiling perl 5.10.1 with the following options ./Configure -des -A ccflags=-O2 -DPERL_USE_SAFE_PUTENV -fPIC -Dusethreads -Duse64bitall \ -Dprefix=/opt/perl -Dinstallprefix=/opt/perl ./Configure -des -A ccflags=-DPERL_USE_SAFE_PUTENV -Accflags=-fPIC -Dusethreads \ -Duse64bitall -Dprefix=/opt/perl -Dinstallprefix=/opt/perl ./Configure -des -A -Dusethreads -Duse64bitall -Dinstallprefix=/opt/perl perl always compiles and seem to work fine with other modules. Mod_perl2.0 build: Both cpan and and the svn checkout version, shows the same error: build cmd: cd '/usr/tmp/cpan_extract/mod_perl-2.0'; /opt/perl/bin/perl Makefile.PL MP_APXS=/opt/apache/bin/apxs cc -shared -O2 -L/usr/local/lib -fstack-protector \ \ mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo modperl_gtop.lo modperl_util.lo modperl_io.lo modperl_io_apache.lo modperl_filter.lo modperl_bucket.lo modperl_mgv.lo modperl_pcw.lo modperl_global.lo modperl_env.lo modperl_cgi.lo modperl_perl.lo modperl_perl_global.lo modperl_perl_pp.lo modperl_sys.lo modperl_module.lo modperl_svptr_table.lo modperl_const.lo modperl_constants.lo modperl_apache_compat.lo modperl_error.lo modperl_debug.lo modperl_common_util.lo modperl_common_log.lo modperl_hooks.lo modperl_directives.lo modperl_flags.lo modperl_xsinit.lo modperl_exports.lo -Wl,-E -fstack-protector -L/usr/local/lib -L/opt/perl/lib/5.10.1/x86_64-linux-thread-multi/CORE -lperl -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc \ -o mod_perl.so /usr/bin/ld: /opt/perl/lib/5.10.1/x86_64-linux-thread-multi/CORE/libperl.a(op.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC /opt/perl/lib/5.10.1/x86_64-linux-thread-multi/CORE/libperl.a: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [mod_perl.so] Error 1 make[1]: Leaving directory
Re: unable to compile mod_perl under perl 5.10.1
Here's what's on my 5.8.8 with fPIC, I haven't tried 5.10.1 on 64 bit yet. cc='cc', ccflags ='-fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', I'm not sure if the perl you showed me below has fpic configured. I recommend that you compile a non-threaded version of perl though in a separate installation location (with fpic configured of course), and then build mod_perl from that. I usually use /home/app_user/perl. There are a couple of reasons to do this: 1) If you start using CPAN with an rpm based distribution such as centos, then you will be installing modules that should be installed via RPM. The Fedora maintainer gave a note on this in a talk a couple years ago at YAPC Chicago. 2) Single threaded perl binaries tend to be faster (~20%) and more stable than threaded perl binaries. I don't have the data to post, but I did some perlbench comparisons a few years ago with 5.8.8. This may have changed with 5.10, but I would consider it unlikely. 3) You can ensure that you have fpic configured. On Tue, Jan 12, 2010 at 12:11 AM, Morten Bjørnsvik morten.bjorns...@experian-da.no wrote: Hi Fred Thanks for the answer. getting correct -fPIC is probably the solution, but how? On perl 5.10.0 it turned up under config flags, but here it does not, but under cccdlflags in dynamic linking? There is probably some parsing in the Configure script that rearrange it. platform is CentOS 5.2 (latest patches) Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=linux, osvers=2.6.18-164.9.1.el5, archname=x86_64-linux-thread-multi uname='linux mortenb5.secana.local 2.6.18-164.9.1.el5 #1 smp tue dec 15 20:57:57 est 2009 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -A ccflags=-DPERL_USE_SAFE_PUTENV -Dusethreads -Dprefix=/opt/perl -Dinstallprefix=/opt/perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-46)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector' -Original Message- From: Fred Moyer [mailto:f...@redhotpenguin.com] Sent: 11. januar 2010 22:29 To: Morten Bjørnsvik Cc: mod_perl list Subject: Re: unable to compile perl under perl 5.10.1 Have you verified perl was actually compiled with fpic? perl -V On Mon, Jan 11, 2010 at 7:23 AM, Morten Bjørnsvik morten.bjorns...@experian-da.no wrote: Hi all I'm unable to compile mod_perl-2.0.x from svn(trunk 2.0.5-dev) or cpan(2.0.4) on perl 5.10.1, do anyone have some black belt options that make it works, I believed the -fPIC now is embedded in the -Dusethreads, because I see it appear lots of places in the perl compile output I've tried compiling perl 5.10.1 with the following options ./Configure -des -A ccflags=-O2 -DPERL_USE_SAFE_PUTENV -fPIC -Dusethreads -Duse64bitall \ -Dprefix=/opt/perl -Dinstallprefix=/opt/perl ./Configure -des -A ccflags=-DPERL_USE_SAFE_PUTENV -Accflags=-fPIC -Dusethreads \ -Duse64bitall -Dprefix=/opt/perl -Dinstallprefix=/opt/perl ./Configure -des -A -Dusethreads -Duse64bitall -Dinstallprefix=/opt/perl perl always compiles and seem to work fine with other modules. Mod_perl2.0 build: Both cpan and and the svn checkout version, shows the same error: build cmd: cd '/usr/tmp/cpan_extract/mod_perl-2.0'; /opt/perl/bin/perl Makefile.PL MP_APXS=/opt/apache/bin/apxs cc -shared -O2 -L/usr/local/lib -fstack-protector \ \ mod_perl.lo modperl_interp.lo modperl_tipool.lo modperl_log.lo modperl_config.lo modperl_cmd.lo modperl_options.lo modperl_callback.lo modperl_handler.lo
RE: unable to compile mod_perl under perl 5.10.1
Hi again I inspected the rpm spec file we use to build perl and found some errors setting it to default value config_args='-des -A ccflags=-fPIC -Dprefix=/opt/perl -Dinstallprefix=/opt/perl' Now mod_perl compiles fine, I will also try without threading based on your comments. (I believed threads were more unstable but not slower). We used 'use Thread;' in earlier version, but I could not find it in the code anymore. Thanks again for some excellent feedback. -- MortenB -Original Message- From: Fred Moyer [mailto:f...@redhotpenguin.com] Sent: 12. januar 2010 09:22 To: Morten Bjørnsvik Cc: mod_perl list Subject: Re: unable to compile mod_perl under perl 5.10.1 Here's what's on my 5.8.8 with fPIC, I haven't tried 5.10.1 on 64 bit yet. cc='cc', ccflags ='-fPIC -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', I'm not sure if the perl you showed me below has fpic configured. I recommend that you compile a non-threaded version of perl though in a separate installation location (with fpic configured of course), and then build mod_perl from that. I usually use /home/app_user/perl. There are a couple of reasons to do this: 1) If you start using CPAN with an rpm based distribution such as centos, then you will be installing modules that should be installed via RPM. The Fedora maintainer gave a note on this in a talk a couple years ago at YAPC Chicago. 2) Single threaded perl binaries tend to be faster (~20%) and more stable than threaded perl binaries. I don't have the data to post, but I did some perlbench comparisons a few years ago with 5.8.8. This may have changed with 5.10, but I would consider it unlikely. 3) You can ensure that you have fpic configured. On Tue, Jan 12, 2010 at 12:11 AM, Morten Bjørnsvik morten.bjorns...@experian-da.no wrote: Hi Fred Thanks for the answer. getting correct -fPIC is probably the solution, but how? On perl 5.10.0 it turned up under config flags, but here it does not, but under cccdlflags in dynamic linking? There is probably some parsing in the Configure script that rearrange it. platform is CentOS 5.2 (latest patches) Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=linux, osvers=2.6.18-164.9.1.el5, archname=x86_64-linux-thread-multi uname='linux mortenb5.secana.local 2.6.18-164.9.1.el5 #1 smp tue dec 15 20:57:57 est 2009 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -A ccflags=-DPERL_USE_SAFE_PUTENV -Dusethreads -Dprefix=/opt/perl -Dinstallprefix=/opt/perl' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=define, use64bitall=define, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-D_REENTRANT -D_GNU_SOURCE -DPERL_USE_SAFE_PUTENV -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.1.2 20080704 (Red Hat 4.1.2-46)', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='cc', ldflags =' -fstack-protector -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib /lib64 /usr/lib64 /usr/local/lib64 libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.5.so, so=so, useshrplib=false, libperl=libperl.a gnulibc_version='2.5' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E' cccdlflags='-fPIC', lddlflags='-shared -O2 -L/usr/local/lib -fstack-protector' -Original Message- From: Fred Moyer [mailto:f...@redhotpenguin.com] Sent: 11. januar 2010 22:29 To: Morten Bjørnsvik Cc: mod_perl list Subject: Re: unable to compile perl under perl 5.10.1 Have you verified perl was actually compiled with fpic? perl -V On Mon, Jan 11, 2010 at 7:23 AM, Morten Bjørnsvik morten.bjorns...@experian-da.no wrote: Hi all I'm unable to compile mod_perl-2.0.x from svn(trunk 2.0.5-dev) or cpan(2.0.4) on perl 5.10.1, do anyone have some black belt options that make it works, I believed the -fPIC now is embedded in the -Dusethreads, because I see it appear lots of places in the perl compile output I've tried compiling perl 5.10.1 with the following options ./Configure -des -A ccflags=-O2 -DPERL_USE_SAFE_PUTENV -fPIC -Dusethreads -Duse64bitall \ -Dprefix=/opt/perl -Dinstallprefix=/opt/perl ./Configure -des -A
SetHandler perl-script not working
Hi all, I have a serious problem with sethandler perl-script not working. For testing I have enabled perl-status: Location /perl-status SetHandler perl-script PerlResponseHandler Apache2::Status Order deny,allow Allow from all /Location ...but I'm still getting 404 for the URL. I'm definitely reading the file as adding a syntax error in the above causes httpd -t to fail. It is quite a complex install though with Drupal and Scalix (which uses tomcat and ajp proxy). Can anyone suggest how to go about fixing this? Thanks Don't worry about the allow from all, it's a private box and I'll remove it again.
Zip on the fly problem
Hi,
I use Archive::Zip to generate zip files on the fly in Modperl 2.04 with
code similar like this:
my $zip = Archive::Zip-new();
my $member = $zip-addFile( '/home/testimg/test1.jpg', 'testfile1.jpg' );
if ($member){
$member-desiredCompressionLevel( 1 );
}
$member = $zip-addFile( '/home/testimg/test2.ppt', 'testfile2.ppt' );
if ($member){
$member-desiredCompressionLevel( 1 );
}
if ( $zip-numberOfMembers() ){
unless ( $zip-writeToFileHandle( \*STDOUT, 0) == Archive::Zip::AZ_OK) {
print STDERR Zip error: $!;
}
}
This works fine with Archive::Zip version 1.26 but fails with version 1.30
I checked the ARchibe::Zip code and could not find anything that can cause
the problem accept for the change from using Compress::Zlib to
Compress::Raw::Zlib.
The error is: 'IO error: seeking to rewrite local header : Invalid argument'
If I use desiredCompressionLevel(0) then there is no problem but no
compression is done.
The error is only related to Mod_perl. As a console script it runs fine.
Problem is on both Windows and Linux (perl 5.10).
Has anyone any idea what might be the problem? or have an alternative
solution?
Thanks,
Thomas den Braber
Re: Zip on the fly problem
On Tuesday 12 January 2010 13:49:34 Thomas den Braber wrote:
I use Archive::Zip to generate zip files on the fly in Modperl 2.04 with
code similar like this:
my $zip = Archive::Zip-new();
my $member = $zip-addFile( '/home/testimg/test1.jpg', 'testfile1.jpg' );
if ($member){
$member-desiredCompressionLevel( 1 );
}
$member = $zip-addFile( '/home/testimg/test2.ppt', 'testfile2.ppt' );
if ($member){
$member-desiredCompressionLevel( 1 );
}
if ( $zip-numberOfMembers() ){
unless ( $zip-writeToFileHandle( \*STDOUT, 0) == Archive::Zip::AZ_OK) {
print STDERR Zip error: $!;
}
}
This works fine with Archive::Zip version 1.26 but fails with version 1.30
I checked the ARchibe::Zip code and could not find anything that can cause
the problem accept for the change from using Compress::Zlib to
Compress::Raw::Zlib.
The error is: 'IO error: seeking to rewrite local header : Invalid
argument'
If I use desiredCompressionLevel(0) then there is no problem but no
compression is done.
The error is only related to Mod_perl. As a console script it runs fine.
Problem is on both Windows and Linux (perl 5.10).
I can only guess here but does your console script write to a pipe or to a
file?
Could you try:
script | cat output.zip
Has anyone any idea what might be the problem? or have an alternative
solution?
Move the ZIP file generation to a PerlFixupHandler and have it write a
temporary file. Then have the default handler ship the file and remove it in a
request pool cleanup or so.
This has the additional benefit of sending a Content-Length header (don't
forget to update $r-finfo) which often leads to faster delivery.
Torsten
Re: SetHandler perl-script not working
Can you post the error message(s)? Theres nothing obviously wrong with what you've got there. Adam Kevin Thorpe wrote: Hi all, I have a serious problem with sethandler perl-script not working. For testing I have enabled perl-status: Location /perl-status SetHandler perl-script PerlResponseHandler Apache2::Status Order deny,allow Allow from all /Location ...but I'm still getting 404 for the URL. I'm definitely reading the file as adding a syntax error in the above causes httpd -t to fail. It is quite a complex install though with Drupal and Scalix (which uses tomcat and ajp proxy). Can anyone suggest how to go about fixing this? Thanks Don't worry about the allow from all, it's a private box and I'll remove it again.
Re: SetHandler perl-script not working
On Tue, Jan 12, 2010 at 6:43 AM, Kevin Thorpe kevin.tho...@pibenchmark.com wrote: Location /perl-status SetHandler perl-script PerlResponseHandler Apache2::Status Order deny,allow Allow from all /Location ...but I'm still getting 404 for the URL. It sounds like something else in your config is intercepting the URL. Try removing other things one chunk at a time until this works. Alternatively, you might be sending your requests to the wrong server or virtual server. - Perrin
Re: Logs show reasonable request handling duration, but proxied clients timing out
On Tue, Jan 5, 2010 at 11:39 AM, eric.b...@barclayscapital.com wrote: The client uses a 500 millisecond read timeout which is often reached, causing the client process to throw exceptions. However, when I look at my logs, the %D param shows durations well below this limit. At times I do not see the requests at all. Sounds like a network problem. What should I be looking at on my servers to see if the problem is on my end? You could try turning off keep-alive, in case the proxy handles that poorly. You could also set up a monitor script to hit the URL every 5 minutes and log the times. Maybe try doing that directly and through the proxy to compare. - Perrin
Apache Blank Pages
Hello, I have a bizarre problem I'm hoping someone could give me some suggestions with. I have a couple of MP2 scripts running on a server, they are both similar in use of modules and structure. Without any recent changes, one of the scripts is producing a blank apache page on SOME requests. It's not always the same function, it can happen to any of the function calls contained in the script. When the blank page happens there is nothing in either the access log or the error log of that virtual host (like the request never made it that far). In the default error log I will get something like [notice] child pid 11497 exit signal Aborted (6) Sometimes (but not always), I'll see *** glibc detected *** malloc(): memory corruption: 0x09c120f8 *** There is also no consistency to the blank page, sometimes you hit the URL and you get the content, sometimes you get a blank page, sometimes 1 refresh on the blank page gives you content, other times it can take 3 - 7 refreshes before the content comes. I've been trying to pull apart my script piece by piece in the hopes that I could at least narrow it down to some specific section but I'm not having a lot of luck. Any thoughts on how I could debug this better? TIA!
Re: Apache Blank Pages
It seems pretty clear the blank pages are from the apache children dieing badly (hence the errors). I would make an educated guess based on the malloc error that your ram is bad. Try running your app on a different box and see if you get the same errors. On Jan 12, 2010 7:19 AM, cfaust-dougot cfa...@doyougot.com wrote: Hello, I have a bizarre problem I'm hoping someone could give me some suggestions with. I have a couple of MP2 scripts running on a server, they are both similar in use of modules and structure. Without any recent changes, one of the scripts is producing a blank apache page on SOME requests. It's not always the same function, it can happen to any of the function calls contained in the script. When the blank page happens there is nothing in either the access log or the error log of that virtual host (like the request never made it that far). In the default error log I will get something like [notice] child pid 11497 exit signal Aborted (6) Sometimes (but not always), I'll see *** glibc detected *** malloc(): memory corruption: 0x09c120f8 *** There is also no consistency to the blank page, sometimes you hit the URL and you get the content, sometimes you get a blank page, sometimes 1 refresh on the blank page gives you content, other times it can take 3 - 7 refreshes before the content comes. I've been trying to pull apart my script piece by piece in the hopes that I could at least narrow it down to some specific section but I'm not having a lot of luck. Any thoughts on how I could debug this better? TIA!
intermittent segfaults, ssl?
Hi, I have a server like this: Server Version: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 I'm also using HTML::Mason I've been getting intermittent segfaults like this: child pid 10142 exit signal Segmentation fault (11) ever since in installed Apache2 in March. I am going to try to debug this, but I thought I would ask if anyone might have a suggestion based on this behavior: - no segfaults occur with 8 hours of an apache restart; the first fault can be 8 to 48 hours after restart, the 2nd may occur within seconds; there have never been more than 5 in a day. - I have observed these faults *only* for port 443 (ssl) requests. - The simplest case has been when a plain HTML page was served through mod_perl and mason; e.g. no database call. I know probably shouldn't be imposing on list-readers time without doing more work, but I just wonder is it isn't something really elementary that I'm missing. Mark
RE: Apache Blank Pages
Thanks for the reply William, at first I thought the same thing but as time went on and this only effected 1 virtual host and not the other (and the other had 10x the traffic), I didn't seem like hardware or config related. I've gotten a little further since my last post, but it still doesn't make sense. If I take the DB connection out of the script, it doesn't happen. I've added and removed it a few times just because I couldn't belive it. The DB is on another machine and both virtual hosts call the same machine (each virtual is a different DB on the dedicated DB server). The only difference in the DB connection call between the 2 scripts is that virtual host 1 calls it via a custom package (as other scripts need the same DB) - this is the site that works. Virtual Host 2 makes the connection within sub handler and that's the one that doesn't work. No closer to a solution though - any method I try to use to connect to the DB from VH2 results in this problem. Still doesn't make a lot of sense. From: William T [mailto:dietbud...@gmail.com] Sent: Tue 1/12/2010 11:47 AM To: cfaust-dougot Cc: modperl@perl.apache.org Subject: Re: Apache Blank Pages It seems pretty clear the blank pages are from the apache children dieing badly (hence the errors). I would make an educated guess based on the malloc error that your ram is bad. Try running your app on a different box and see if you get the same errors. On Jan 12, 2010 7:19 AM, cfaust-dougot cfa...@doyougot.com wrote: Hello, I have a bizarre problem I'm hoping someone could give me some suggestions with. I have a couple of MP2 scripts running on a server, they are both similar in use of modules and structure. Without any recent changes, one of the scripts is producing a blank apache page on SOME requests. It's not always the same function, it can happen to any of the function calls contained in the script. When the blank page happens there is nothing in either the access log or the error log of that virtual host (like the request never made it that far). In the default error log I will get something like [notice] child pid 11497 exit signal Aborted (6) Sometimes (but not always), I'll see *** glibc detected *** malloc(): memory corruption: 0x09c120f8 *** There is also no consistency to the blank page, sometimes you hit the URL and you get the content, sometimes you get a blank page, sometimes 1 refresh on the blank page gives you content, other times it can take 3 - 7 refreshes before the content comes. I've been trying to pull apart my script piece by piece in the hopes that I could at least narrow it down to some specific section but I'm not having a lot of luck. Any thoughts on how I could debug this better? TIA!
Re: intermittent segfaults, ssl?
We had a very similar problem. After a lot of effort trying to track down the source, we believe we isolated it to a line of perl code that incorrectly sets $/ without localizing it. mod_backtrace showed that the problem seemed to be happening in modperl_perl_global_request_save Here is the thread that suggested the fix that worked for us: http://www.gossamer-threads.com/lists/modperl/modperl/100066 Here is the thread we posted, not actually any more informative: http://www.gossamer-threads.com/lists/modperl/modperl/100842 The proof is in the pudding. After fixing the line with $/, we went from dozens of seg faults per hour to none. - Alex Aminoff BaseSpace.net National Bureau of Economic Research (nber.org) On Tue, 12 Jan 2010, Mark Copper wrote: Hi, I have a server like this: Server Version: Apache/2.2.9 (Debian) mod_ssl/2.2.9 OpenSSL/0.9.8g mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 I'm also using HTML::Mason I've been getting intermittent segfaults like this: child pid 10142 exit signal Segmentation fault (11) ever since in installed Apache2 in March. I am going to try to debug this, but I thought I would ask if anyone might have a suggestion based on this behavior: - no segfaults occur with 8 hours of an apache restart; the first fault can be 8 to 48 hours after restart, the 2nd may occur within seconds; there have never been more than 5 in a day. - I have observed these faults *only* for port 443 (ssl) requests. - The simplest case has been when a plain HTML page was served through mod_perl and mason; e.g. no database call. I know probably shouldn't be imposing on list-readers time without doing more work, but I just wonder is it isn't something really elementary that I'm missing. Mark
Re: Zip on the fly problem
Not satisfied with the size of your file?
Re: Zip on the fly problem
On Tue, Jan 12, 2010 at 7:49 AM, Thomas den Braber tho...@delos.nl wrote: [ ... ] The error is: 'IO error: seeking to rewrite local header : Invalid argument' That error means that after writing something to the ZIP archive, it tried to go backwards to put what it just wrote in the header, but found it couldn't do that because it's output is going over the network and what's already sent can't be changed. A temporary file is certainly one fix, as people here have suggested. The fact that it used to work means that it must be possible to generate a ZIP file without seeking around, so my advice would be to poke around in the options and see if you find anything useful. Hope this is at least a little helpful! Scott.
Re: Zip on the fly problem
On Tue, Jan 12, 2010 at 10:11:04PM -0500, Scott Gifford wrote: On Tue, Jan 12, 2010 at 7:49 AM, Thomas den Braber tho...@delos.nl wrote: [ ... ] The error is: 'IO error: seeking to rewrite local header : Invalid argument' That error means that after writing something to the ZIP archive, it tried to go backwards to put what it just wrote in the header, but found it couldn't do that because it's output is going over the network and what's already sent can't be changed. A temporary file is certainly one fix, as people here have suggested. The fact that it used to work means that it must be possible to generate a ZIP file without seeking around, so my advice would be to poke around in the options and see if you find anything useful. The second argument to writeToFileHandle is supposed to address that: writeToFileHandle( $fileHandle [, $seekable] ) Write a zip archive to a file handle. Return AZ_OK on success. The optional second arg tells whether or not to try to seek backwards to re-write headers. ... If you pass a file handle that is not seekable (like if you're writing to a pipe or a socket), pass a false second argument: ... Thomas, are you sure the actual code in question is passing a false value as the second argument? Ronald
Re: Zip on the fly problem
Yes I am sure that second argument is false. In the old version I only used one argument but changed the second to 0 hoping that solved the problem. As Torsten was suggesting, I tested with: script | cat file And yes that also fails with Archive::Zip 1.30 and worked ok with 1.26 script file Worked in both versions. There is something wrong in the new Archive::Zip module I send a message to the CPAN forum hope they pick it up. Thank, Thomas den Braber -Original Message- From: Ronald J Kimball rjk-perl-modp...@tamias.net To: Scott Gifford sgiff...@suspectclass.com Cc: Thomas den Braber tho...@delos.nl, modperl@perl.apache.org Date: Tue, 12 Jan 2010 23:06:49 -0500 Subject: Re: Zip on the fly problem On Tue, Jan 12, 2010 at 10:11:04PM -0500, Scott Gifford wrote: On Tue, Jan 12, 2010 at 7:49 AM, Thomas den Braber tho...@delos.nl wrote: [ ... ] The error is: 'IO error: seeking to rewrite local header : Invalid argument' That error means that after writing something to the ZIP archive, it tried to go backwards to put what it just wrote in the header, but found it couldn't do that because it's output is going over the network and what's already sent can't be changed. A temporary file is certainly one fix, as people here have suggested. The fact that it used to work means that it must be possible to generate a ZIP file without seeking around, so my advice would be to poke around in the options and see if you find anything useful. The second argument to writeToFileHandle is supposed to address that: writeToFileHandle( $fileHandle [, $seekable] ) Write a zip archive to a file handle. Return AZ_OK on success. The optional second arg tells whether or not to try to seek backwards to re-write headers. ... If you pass a file handle that is not seekable (like if you're writing to a pipe or a socket), pass a false second argument: ... Thomas, are you sure the actual code in question is passing a false value as the second argument? Ronald
