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

Hi Fred, modperl folks:

We've narrowed down this bug a bit more.  We are currently running perl 
5.16.1 (latest), the latest mod_perl from source and apache version 
2.2.22.

If we run a simple httpd.conf with this line:

PerlModule Carp

Then single-process startup will fail on the second perl startup.
(perl starts up twice when apache is started, as explained in 
http://perl.apache.org/docs/2.0/user/handlers/server.html).

httpd -X
(segmentation fault)

We can tell that apache starts up perl successfully the first time by 
running strace.  The segfault can be traced to one line in Carp.pm:

--------------------%<----------------------------------------------------
# Transform an argument to a function into a string.
sub format_arg {

...

     # The following handling of "control chars" is direct from
     # the original code - it is broken on Unicode though.
     # Suggestions?
     is_utf8($arg) or $arg =~ s/([[:cntrl:]]|[[:^ascii:]])/sprintf("\\x{%x}",ord($1))/eg;
     return $arg;
}
--------------------%<-------------------------------------------------------

If we comment out the line which starts 'is_utf8...' then the segfault is 
prevented.  It strikes me as odd that just *compiling* that line (which is 
legal perl) should cause a segfault, but that is what we repeatedly 
observe.

Any ideas or thoughts welcome!

Regards,

   Doug Hunt

[email protected]
Software Engineer
UCAR - COSMIC, Tel. (303) 497-2611

On Tue, 14 Aug 2012, 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
>