Re: [mp2] mod_perl 2.0.7 Segfault When Loading Certain Perl Module

Hello Fred,

Thank you for pointing out the upcoming release. Unfortunately, after 
checking out and installing the latest version from SVN, I'm still 
seeing the same issue. Apache still segfault while trying to load any 
Perl module that directly or indirectly use Carp. According to "SVN info 
-r HEAD", the reversion I'm using is 1373130.

One thing I noticed from strace is that the module seems to be loaded 
successfully the first time ( according to mod_perl2 doc, Apache 2 will 
perform a restart right after initial start. so every module will be 
loaded twice... ), and only when it is to be loaded the second time the 
segfault occurs. Perhaps there are some differences between the first 
and second module load during apache/mod_perl initialization that's 
causing the segfault?


Best,
Jason

On 08/14/2012 12:17 PM, Fred Moyer wrote:
> Can you try the latest version from source?
>
> http://perl.apache.org/download/source.html
>
> It looks like you are using perl 5.16, some recent fixes were
> committed there. The subversion tip will likely be the 2.0.8 RC in a
> week or so.
>
> On Mon, Aug 13, 2012 at 3:01 PM, Jason Lin <[email protected]> wrote:
>> Hi,
>>
>> I work for a project that has been using mod_perl for quite a while.
>> Recently, we upgraded our 64-bit web server with Perl 5.16, mod_perl 2.0.7
>> (it's 2.0.6 with patch), and apache 2.2.22 on CentOS 6.3. Since then, we've
>> been unable to start Apache server (segmentation faults) with same
>> httpd.conf which worked previously.
>>
>> As far as I can tell, the segfault seems to be triggered while trying to
>> load any Perl module using either PerlModule directive or in <Perl> block in
>> httpd.conf that directly or indirectly use Carp, or even just try to load
>> Carp itself. Strace shows that the process would segfault while loading (or
>> right after loading) Carp.pm. The server can still successfully start and
>> work when carefully removing such modules in httpd.conf.
>>
>> Is anyone seeing this same issue or have any ideas how it can be fixed other
>> than trying to hack through all the Perl modules to make sure Carp is not
>> called?
>>
>>
>> perl -V
>> Summary of my perl5 (revision 5 version 16 subversion 0) configuration:
>>
>>    Platform:
>>      osname=linux, osvers=2.6.32-279.1.1.el6.x86_64, archname=x86_64-linux
>>      uname='linux fox.cosmic.ucar.edu 2.6.32-279.1.1.el6.x86_64 #1 smp tue
>> jul 10 13:47:21 utc 2012 x86_64 x86_64 x86_64 gnulinux '
>>      config_args='-Dprefix=/ops/tools -des
>> -Accflags=-DPERL_RELOCATABLE_INCPUSH'
>>      hint=recommended, useposix=true, d_sigaction=define
>>      useithreads=undef, usemultiplicity=undef
>>      useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>>      use64bitint=define, use64bitall=define, uselongdouble=undef
>>      usemymalloc=n, bincompat5005=undef
>>    Compiler:
>>      cc='cc', ccflags ='-DPERL_RELOCATABLE_INCPUSH -fno-strict-aliasing -pipe
>> -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE
>> -D_FILE_OFFSET_BITS=64',
>>      optimize='-O2',
>>      cppflags='-DPERL_RELOCATABLE_INCPUSH -fno-strict-aliasing -pipe
>> -fstack-protector -I/usr/local/include'
>>      ccversion='', gccversion='4.4.6 20120305 (Red Hat 4.4.6-4)',
>> 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/../lib64 /usr/lib/../lib64 /lib /usr/lib
>> /lib64 /usr/lib64 /usr/local/lib64
>>      libs=-lnsl -lgdbm -ldl -lm -lcrypt -lutil -lc
>>      perllibs=-lnsl -ldl -lm -lcrypt -lutil -lc
>>      libc=, so=so, useshrplib=false, libperl=libperl.a
>>      gnulibc_version='2.12'
>>    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'
>>
>>
>> Characteristics of this binary (from libperl):
>>    Compile-time options: HAS_TIMES PERLIO_LAYERS PERL_DONT_CREATE_GVSV
>>                          PERL_MALLOC_WRAP PERL_PRESERVE_IVUV
>>                          PERL_RELOCATABLE_INCPUSH USE_64_BIT_ALL
>>                          USE_64_BIT_INT USE_LARGE_FILES USE_LOCALE
>>                          USE_LOCALE_COLLATE USE_LOCALE_CTYPE
>>                          USE_LOCALE_NUMERIC USE_PERLIO USE_PERL_ATOF
>>    Built under linux
>>    Compiled at Aug  1 2012 16:14:39
>>    %ENV:
>>      PERL5LIB="/ops/tools/lib"
>>    @INC:
>>      /ops/tools/lib
>>      /ops/tools/lib/perl5/site_perl/5.16.0/x86_64-linux
>>      /ops/tools/lib/perl5/site_perl/5.16.0
>>      /ops/tools/lib/perl5/5.16.0/x86_64-linux
>>      /ops/tools/lib/perl5/5.16.0
>>      .
>>
>> Note that we compiled Perl with relocation flag (-DPERL_RELOCATABLE_INCPUSH)
>> turned on, yet same issue can also be found without the flag in our test.
>>
>> Any help/advice would be appreciated, thank you in advance.
>>
>>
>> Best,
>> Jason