The problem was that the way I built Perl (see below)
ended up setting -D_FILE_OFFSET_BITS=64 as a C flag.
I assume that this is the default on my platform.
This results in struct stat being changed to
struct stat64 (which is 16 bytes larger). As this
structure is inside an Apache request structure,
this meant that mod_perl and Apache did not agree on
the offsets of the structure members that occurred
after the finfo member. Hence the segfault.
I now have it working, although I'm not happy with the
build procedure. The first thing I tried is to build
Apache setting -D_FILE_OFFSET_BITS=64. This lead to
more and more segfaults so I quickly abandoned this
idea.
The way I built it is exactly as before except that I
no longer include DO_HTTPD. Instead I do the
perl Makefile.PL for mod_perl with all its arguments.
Then I go to the apache directory and do:
perl -i -ple 's/-D_FILE_OFFSET_BITS=64//' \
`find . -name Makefile -print`
I then do make and make install and everything is cozy.
Question: is there anyway that I can do the same with
command line arguments without having to patch the Makefile's
(a goal here was not to have to rebuild Perl yet again)?
-Paul
-----Original Message-----
From: Paul G. Weiss
Sent: Monday, April 03, 2000 9:38 AM
To: 'Doug MacEachern'
Cc: [EMAIL PROTECTED]
Subject: RE: mod_perl (DSO) dumping core with perl 5.6.0
Sad to say still not working.
This time I built perl:
./configure \
-Ubincompat5005 \
-Dprefix=/usrl1/home/pweiss/perl-56 \
-Doptimize='-O -g' \
-Dcc=gcc \
-Uinstallusrbinperl \
-Accflags=-DPERL_POLLUTE
(the -Accflags argument is to avoid having to build
certain extensions with POLLUTE=1 on the advice of
Jason Kirtland),
built modperl (from CVS, with Changes version = 1.458)
perl Makefile.PL \
EVERYTHING=1 \
PERL_TRACE=1 \
USE_DSO=1 \
PERL_MARK_WHERE=1 \
APACHE_SRC=../apache_1.3.12/src \
DO_HTTPD=1 \
APACI_ARGS='--prefix=/usrl1/home/pweiss/apache \
--enable-module=rewrite --enable-module=proxy \
--enable-shared=max'
Now apache starts up OK, but *any* request results in
a segfault:
Program received signal SIGSEGV, Segmentation fault.
0xef1c45c0 in perl_header_parser (r=0x157060) at mod_perl.c:1008
(gdb) bt
#0 0xef1c45c0 in perl_header_parser (r=0x157060) at mod_perl.c:1008
#1 0x20380 in run_method ()
#2 0x20574 in ap_header_parse ()
#3 0x3c7fc in process_request_internal ()
#4 0x3cd0c in ap_process_request ()
#5 0x309b4 in child_main ()
#6 0x30c1c in make_child ()
#7 0x30e1c in startup_children ()
#8 0x31700 in standalone_main ()
#9 0x322ac in main ()
This location corresponds to this line in source:
#ifdef PERL_HEADER_PARSER
int PERL_HEADER_PARSER_HOOK(request_rec *r)
{
dSTATUS;
=> dPPDIR;
#ifdef PERL_INIT
PERL_CALLBACK("PerlInitHandler",
cld->PerlInitHandler);
#endif
PERL_CALLBACK("PerlHeaderParserHandler",
cld->PerlHeaderParserHandler);
return status;
}
#endif
> -----Original Message-----
> From: Doug MacEachern [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 03, 2000 12:17 AM
> To: Paul G. Weiss
> Cc: [EMAIL PROTECTED]
> Subject: RE: mod_perl (DSO) dumping core with perl 5.6.0
>
>
> On Fri, 31 Mar 2000, Paul G. Weiss wrote:
>
> > I was afraid of that, given that the fault was in malloc.c.
> > Is there no hope, then? Is there anything I can do to help
> > diagnose/fix the problem? I've heard that Perl's malloc is
> > much better that the malloc on Solaris, so I'm not eager to
> > throw in the towel.
>
> there is better than hope, the solution is to configure Perl with
> -Ubincompat5005
>
> this will require that you re-build any site_perl xs modules.
>
