Hello there, On Fri, 18 Oct 2002 [EMAIL PROTECTED] wrote:
> Hardware is definitely not at fault. > [snip] > >>Some info: > >>/usr/apache-perl/bin/httpd -l > >>Compiled-in modules: > >> http_core.c > >> mod_env.c > >> mod_log_config.c > >> mod_mime.c > >> mod_negotiation.c > >> mod_status.c > >> mod_include.c > >> mod_autoindex.c > >> mod_dir.c > >> mod_cgi.c > >> mod_asis.c > >> mod_imap.c > >> mod_actions.c > >> mod_userdir.c > >> mod_alias.c > >> mod_access.c > >> mod_auth.c > >> mod_so.c > >> mod_setenvif.c > >> mod_php4.c > >> mod_perl.c > >> [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 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. 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? 73, Ged.
