Bug #69687 for Test-Simple: Using Test::More with mod_perl: segfault

Hi, Thanks for a quick response. This is the first time I've used mod_perl in years, too. I'm working in a controlled environment (i.e. on servers that are configured and maintained by someone else, according to strict rules of their own) so I won't easily be able to do some of these tests. $ perl -e 'use Test::More; print $Test::More::VERSION;' 0.92 Test code was trivial (see below). This was produced by progressively stripping more and more code from a failing script until I was left with what you see here. Executing this script would reliably cause segfaults after several reloads of the page (possibly where several == number of apache children allowed). I don’t think there are any threads in use. I will request access to a system with the latest mod_perl and Test::More installed and let you know if I can get any useful test results. Note that I suspect the problem is not in Test::More itself but deeper, in one of the modules it depends on. See also: http://stackoverflow.com/questions/4413411/mod-perl-segmentation-fault Per you other email, perl -V o/p appended below. Also: $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.1 (Santiago) HTH Merlyn -------------------------------------------------------------------------------------------------------------- $|=1; use strict; use utf8; use locale; use Test::More; main(); sub main { print "Content-Type: text/html\r\n\r\nhello "; open TEST, "|/bin/cat"; print TEST "HELLO WORLD\n"; close TEST; print "world\n"; } -------------------------------------------------------------------------------------------------------------- $ perl -V Summary of my perl5 (revision 5 version 10 subversion 1) configuration: Platform: osname=linux, osvers=2.6.18-194.26.1.el5, archname=x86_64-linux-thread-multi uname='linux x86-003.build.bos.redhat.com 2.6.18-194.26.1.el5 #1 smp fri oct 29 14:21:16 edt 2010 x86_64 x86_64 x86_64 gnulinux ' config_args='-des -Doptimize=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DDEBUGGING=-g -Dversion=5.10.1 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl5 -Dsitearch=/usr/local/lib64/perl5 -Dprivlib=/usr/share/perl5 -Darchlib=/usr/lib64/perl5 -Dvendorlib=/usr/share/perl5/vendor_perl -Dvendorarch=/usr/lib64/perl5/vendor_perl -Dinc_version_list=5.10.0 -Darchname=x86_64-linux-thread-multi -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl=n -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr -Dd_gethostent_r_proto -Ud_endhostent_r_proto -Ud_sethostent_r_proto -Ud_endprotoent_r_proto -Ud_setprotoent_r_proto -Ud_endservent_r_proto -Ud_setservent_r_proto -Dscriptdir=/usr/bin' 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='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic', cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include' ccversion='', gccversion='4.4.4 20100726 (Red Hat 4.4.4-13)', 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='gcc', ldflags =' -fstack-protector' libpth=/usr/local/lib64 /lib64 /usr/lib64 libs=-lresolv -lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.12' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib64/perl5/CORE' cccdlflags='-fPIC', lddlflags='-shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API Built under linux Compiled at Apr 19 2011 15:27:31 %ENV: PERL5LIB="/jobsite/perlcore/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi:/jobsite/perlcore/lib/perl5/site_perl/5.8.8:/jobsite/perlcore/lib/perl5/5.8.8:/jobsite/perlcore/lib/perl5:/jobsite/perlmodules/:/jobsite/perlcore/share/perl5:/jobsite/perlcore/lib64/perl5:/jobsite/perlcore/bin" @INC: /jobsite/perlcore/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /jobsite/perlcore/lib/perl5/site_perl/5.8.8 /jobsite/perlcore/lib/perl5/5.8.8 /jobsite/perlcore/lib/perl5 /jobsite/perlmodules/ /jobsite/perlcore/share/perl5 /jobsite/perlcore/lib64/perl5 /jobsite/perlcore/bin /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 . Show quoted text

Thanks for this. The project that exhibited that problem has since died and I've moved on to pastures new so it may take me a short while to resurrect the test environment in order to do this. I'll try and give it a go, though, and let you know what I discover. Merlyn Show quoted text

OK, after my last message I woke up a bit. Made a local copy of Test::Builder and did some simple debugging. This code already has calls to _ copy_io_layers() commented out but it is the routine they were in that causes the problem so your instinct was good. The routine in question is _ open_testhandles() - I've appended the code below in case my version is different from yours for some reason. If I put a return at the start of this routine then the fault goes away. Merlyn sub _open_testhandles { my $self = shift; return if $self->{Opened_Testhandles}; # We dup STDOUT and STDERR so people can change them in their # test suites while still getting normal test output. open( $Testout, ">&STDOUT" ) or die "Can't dup STDOUT: $!"; open( $Testerr, ">&STDERR" ) or die "Can't dup STDERR: $!"; # $self->_copy_io_layers( \*STDOUT, $Testout ); # $self->_copy_io_layers( \*STDERR, $Testerr ); $self->{Opened_Testhandles} = 1; return; } Show quoted text

Hmmm... not that simple I'm afraid :( If I include your suggested BEGIN block instead of my copy of Test::Builder then the fault goes away. If I comment out the two corresponding lines from my copy of Test::Builder then the fault goes away. So I guess it must be some interaction with the duplicated file handles that causes the problem, possibly involving one of the other loaded modules. I've tried a few things and not come up with anything useful yet. I've got to move on now but I'll get back to it later and let you know what I discover. I don't doubt that mod_perl does evil things to STDOUT and STDERR - it'd pretty much have to, really. I guess you can tell whether you're running in a mod_perl environment but what, if anything, you could do with that information to mitigate this problem I don't know (yet). I agree WRT threads - that was more of a facetious "Arggh! Threads!" kind of comment really. Sorry. Merlyn Show quoted text

Show quoted text
Yes - I'll see if I can put something together for them. I'll let you know the outcome in case you hear from others. Show quoted text
Indeed. This is the first project I've done on Redhat (rather than Debian) for a very long time so I wouldn't be surprised either. When I originally had this problem I found a couple of other reports on forums that seemed related but no constructive responses. I guess I'm not the first to see this but it doesn't seem rife, which is perhaps odd. Anyway, more news when I have it. Merlyn