>Because you are running under gdb. If you run normally and arrange for the
>system to allow the core files (as explained in the doc) you will get one.'
>
>Now how do you know that the process 3196 is the one that serves the
>request? I assume that you run under httpd -X? But it doesn't seem to be
>the case, since gdb didn't report the segfault event. (or did it?)
>
>Did you compare the compile time flags as I've suggested?
Yes.
[EMAIL PROTECTED] mod_perl-1.29]# gdb ../apache_1.3.33/src/httpd
GNU gdb Red Hat Linux (5.2-2)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run -X -f /usr/local/apache/conf/httpd.test.conf -d `pwd`/t
Starting program: /usr/local/src/apache_1.3.33/src/httpd -X -f
/usr/local/apache/conf/httpd.test.conf -d `pwd`/t
Program received signal SIGSEGV, Segmentation fault.
0x40338d87 in php_xbithack_handler (r=0x811e5f4)
at /usr/local/src/php-4.3.9/sapi/apache/mod_php4.c:828
828 per_dir_conf = (HashTable *)
get_module_config(r->per_dir_config, &php4_module);
(gdb) bt
#0 0x40338d87 in php_xbithack_handler (r=0x811e5f4)
at /usr/local/src/php-4.3.9/sapi/apache/mod_php4.c:828
#1 0x0806b3af in ap_invoke_handler (r=0x811e5f4) at http_config.c:475
#2 0x08080f23 in process_request_internal (r=0x811e5f4)
at http_request.c:1298
#3 0x08081381 in ap_internal_redirect (new_uri=0x811e5cc "/index.html",
r=0x811d7e4) at http_request.c:1435
#4 0x0805fbf0 in handle_dir (r=0x811d7e4) at mod_dir.c:131
#5 0x0806b3af in ap_invoke_handler (r=0x811d7e4) at http_config.c:475
#6 0x08080f23 in process_request_internal (r=0x811d7e4)
at http_request.c:1298
#7 0x08080f84 in ap_process_request (r=0x811d7e4) at http_request.c:1314
#8 0x08077c45 in child_main (child_num_arg=0) at http_main.c:4786
#9 0x08077df0 in make_child (s=0x80b3114, slot=0, now=1100480122)
at http_main.c:4901
#10 0x08077f64 in startup_children (number_to_start=5) at http_main.c:4983
#11 0x0807866e in standalone_main (argc=6, argv=0xbffff9a4)
at http_main.c:5315
#12 0x08078ed3 in main (argc=6, argv=0xbffff9a4) at http_main.c:5657
#13 0x40098777 in __libc_start_main (main=0x8078b2c <main>, argc=6,
ubp_av=0xbffff9a4, init=0x804e918 <_init>, fini=0x8096e30 <_fini>,
rtld_fini=0x4000dd34 <_dl_fini>, stack_end=0xbffff99c)
at ../sysdeps/generic/libc-start.c:129
Seems to suggest a problem/conflict with the PHP DSO module. Nevertheless, as
I
have said, rebuilding apache without mod_perl (but keeping PHP) clears up the
problem. mod_perl and PHP are the only externals involved in the config of
apache--no other non-default modules.
BTW, I have reproduced this on a more modern Linux, RedHat Enterprise WS,
kernel
2.4.21-20.EL
--
Tim Evans, TKEvans.com, Inc. | 5 Chestnut Court
[EMAIL PROTECTED] | Owings Mills, MD 21117
http://www.tkevans.com/ | 443-394-3864
http://www.come-here.com/News/ |
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
