Ged Haywood wrote:
Hello there,
On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote:
Hardware is definitely not at fault.
[snip]
[snip]
[snip]
first backtrace shows the segfault happening in mod_perl_sent_header(),
and the second shows it happening in the ap_make_array() which was from
Apache::Cookie. I don't have one handy now, but I've also seen it happen
in ap_soft_timeout() after an XS_Apache_print (r->server was out of bounds).
[snip,snip,snip]
I saw another reply to your post talking about the way mod_perl was
built. Could you let us know what the directory tree looked like as
far as the top level of the Apache and mod_perl directories? That
should only take two lines of text, if not then that might be a clue.
I ask because I had a strange problem several years ago when I first
built mod_perl because I had
/usr/local/apache_1.xx
and
/usr/local/apache_1.xx/mod_perl-1.xx
I keep mod_perl in /usr/src/mod_perl-1.27 and apache in
/usr/src/apache_1.3.26
which is definitely not the right way to do it. In view of the fact
that your segfaults seem to be happening in unrelated parts of the
server I'm tempted to say that it must be something pretty fundamental.
yeah, the request_rec is all smashed up.
But that's just a gut feeling, no real reason that I can point to.
Have you tried pulling out as many modules as possible from the build
to see if anything changes, and then adding them back say as a DSO or
one at a time?
I've got nothing non-standard other than php and mod_perl compiled in.
I'm going to try removing some of the standard modules and test.
73,
Ged.
--
--
Daniel Bohling
NewsFactor Network
