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

dh...@ucar.edu
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 <jason...@ucar.edu> 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

Reply via email to