mod_perl 1.27 core dumping on all requests
mod_perl 1.27, apache 1.3.26, Solaris 2.8/Sparc, Perl 5.6, gcc 2.95.2 My problem, I get a consistent core dump in perl_handler(), mod_perl.c:842 on a standard (non-perl script) request in my server as specced above. I've debugged it to where I know what's happening, but have no clue why it's doing so. I make a simple request. I do a telnet, then: GET / HTTP/1.0[ret][ret] and the server processes the request. For some reason it goes though perl_handler()/mod_perl, my understanding was it wouldn't even go though perl_handler() unless I configured a directory with SetHandler. Anyways, it "executes" the macros that start that function, and dies on the dPPDIR macro (from mod_perl.h). That macro tries to get the perl per_directory_config based on the request_req per_dir_config. The problem is, the request doesn't have any r->per_dir_config, so it's NULL, and tries to dereference NULL, and, well, you know what happens. This has happened with various configurations. The weird thing is that it happens at the doc root directory, which has the default per-dir config from httpd.conf. Anyone with any ideas? Richard Homolka Technical Architecture Citadel Investment Group L.L.C. Phone: 312-384-2982 Cell: 312-952-8762 E-Mail: [EMAIL PROTECTED]
RE: Core dumping
On Sat, 9 Sep 2000, Shane Adams wrote:
> #7 0x80894de in XS_Apache_finfo (cv=0x8207410) at Apache.xs:1844
i haven't tried to reproduce this, but suspect a bug in $r->finfo which
the patch below should workaround.
--- lib/HTML/Mason/ApacheHandler.pm~Thu Aug 24 22:42:51 2000
+++ lib/HTML/Mason/ApacheHandler.pm Mon Sep 11 11:43:02 2000
@@ -531,7 +531,7 @@
# If filename is a directory, then either decline or simply reset
# the content type, depending on the value of decline_dirs.
#
-if (-d $r->finfo) {
+if (-d $r->filename) {
if ($self->decline_dirs) {
return DECLINED;
} else {
@@ -544,7 +544,7 @@
# (mainly for dhandlers).
#
my $pathname = $r->filename;
-$pathname .= $r->path_info unless -f $r->finfo;
+$pathname .= $r->path_info unless -f _;
#
# Compute the component path via the resolver.
@@ -555,7 +555,7 @@
#
# Decline if file does not pass top level predicate.
#
-if (-f $r->finfo and defined($self->{top_level_predicate})) {
+if (-f _ and defined($self->{top_level_predicate})) {
return NOT_FOUND unless $self->{top_level_predicate}->($r->filename);
}
RE: Core dumping
Title: Core dumping Sorry I forgot to include the stack trace with debugging turned on: #0 0x81714f7 in Perl_dounwind (cxix=3) at pp_ctl.c:1254#1 0x8171bd1 in Perl_die_where ( message=0x848eb68 "Can't upgrade that kind of scalar at /home/shane/sparty/runtime/perl/lib/site_perl/5.6.0/HTML/Mason/ApacheHandler.pm line 547.\n", msglen=127) at pp_ctl.c:1371#2 0x81289f3 in Perl_vcroak (pat=0x81cc200 "Can't upgrade that kind of scalar", args=0xb284) at util.c:1623#3 0x8128ad1 in Perl_croak (pat=0x81cc200 "Can't upgrade that kind of scalar") at util.c:1670#4 0x814317a in Perl_sv_upgrade (sv=0x81eff50, mt=13) at sv.c:916#5 0x80e5ef0 in Perl_gv_init (gv=0x81eff50, stash=0x81efed8, name=0x81accb6 "_", len=1, multi=0) at gv.c:93#6 0x80e76c3 in Perl_gv_fetchpv (nambeg=0x81accb6 "_", add=1, sv_type=15) at gv.c:681#7 0x80894de in XS_Apache_finfo (cv=0x8207410) at Apache.xs:1844#8 0x8140fc5 in Perl_pp_entersub () at pp_hot.c:2533#9 0x813891a in Perl_runops_debug () at run.c:56#10 0x80e256f in S_call_body (myop=0xb6f8, is_eval=0) at perl.c:1761#11 0x80e21c0 in perl_call_sv (sv=0x85d1ee8, flags=4) at perl.c:1677#12 0x807474c in perl_call_handler (sv=0x85d1ee8, r=0x86d227c, args=0x0) at mod_perl.c:1643#13 0x8073e7a in perl_run_stacked_handlers (hook=0x81aa2b9 "PerlHandler", r=0x86d227c, handlers=0x85d7d80) at mod_perl.c:1362#14 0x8072011 in perl_handler (r=0x86d227c) at mod_perl.c:905#15 0x809e353 in ap_invoke_handler ()#16 0x80b1969 in process_request_internal ()#17 0x80b19cc in ap_process_request ()#18 0x80a926e in child_main ()#19 0x80a93fc in make_child ()#20 0x80a9559 in startup_children ()#21 0x80a9b86 in standalone_main ()#22 0x80aa313 in main ()#23 0x400d31eb in __libc_start_main (main=0x80a9fcc , argc=2, argv=0xb944, init=0x8062820 <_init>, fini=0x81a73cc <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:90(gdb) q -Original Message-----From: Shane Adams Sent: Saturday, September 09, 2000 5:34 PMTo: ModperlSubject: RE: Core dumping I was able to build mod_perl/apache with debugging. The line at which apache drops is: Program received signal SIGSEGV, Segmentation fault.0x81714f7 in Perl_dounwind (cxix=3) at pp_ctl.c:12541254 POPSUB(cx,sv); So it looks like in Perl_dounwind a seg fault is received on line 1254 in pp_ctl.c (course you could probably tell that =) To bad I can't take a peek into the POPSUB macro itself... It's like 20 lines long and there is no way to get gdb to display the macro. Least no way I know. Shane How the hell do people actually try to fix this? The learning curve on trying to understand the internals of perl is enormous! -Original Message-----From: Shane Adams Sent: Friday, September 08, 2000 10:38 PMTo: ModperlSubject: Core dumping Hello - I am experiencing a situation where apache core dumps. We are using HTML-Mason. The relevant revision numbers are: Apache_1.3.12 mod_perl-1.24 perl-5.6.0 HTML-Mason .87 redhat 6.1 (no patches) Our apache server is built in 2 flavors, one that uses Mason, another that doesn but uses mod_perl. httpd-mason -l reveals Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c whereas httpd-soap (straight mod_perl, but it is used to answer SOAP requests via SOAP.pm) http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c Running a barebonse component (nothing tricky, just loads a normal html component) under Mason causes apache to core dump after a few dozen requests. A stack trace reveals: eading symbols from /lib/libnss_nis.so.2...done. #0 0x8143b34 in Perl_pp_entersub () (gdb) where #0 0x8143b34 in Perl_pp_entersub () #1 0x813aeda in Perl_runops_debug () #2 0x80e4b2f in perl_call_sv () #3 0x80e4780 in perl_call_sv () #4 0x8075aac in perl_call_handler () #5 0x8074fd8 in perl_run_stacked_handlers () #6 0x80726a8 in perl_handler () #7 0x80a0913 in ap_invoke_handler () #8 0x80b3f29 in ap_some_auth_required () #9 0x80b3f8c in ap_process_request () #10 0x80ab82e in ap_child_terminate () #11 0x80ab9bc in ap_child_terminate () #12 0x80abb19 in ap_child_terminate () #13 0x80ac146 in ap_child_terminate () #14 0x80ac8d3 in main () #15 0x400d31eb in __libc_start_main (main=0x80ac58c , argc=2, argv=0xb944, init=0x806286c <_init>, fini=0x81a998c <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xb93c) at ../sysd
RE: Core dumping
Title: Core dumping I was able to build mod_perl/apache with debugging. The line at which apache drops is: Program received signal SIGSEGV, Segmentation fault.0x81714f7 in Perl_dounwind (cxix=3) at pp_ctl.c:12541254 POPSUB(cx,sv); So it looks like in Perl_dounwind a seg fault is received on line 1254 in pp_ctl.c (course you could probably tell that =) To bad I can't take a peek into the POPSUB macro itself... It's like 20 lines long and there is no way to get gdb to display the macro. Least no way I know. Shane How the hell do people actually try to fix this? The learning curve on trying to understand the internals of perl is enormous! -Original Message-From: Shane Adams Sent: Friday, September 08, 2000 10:38 PMTo: ModperlSubject: Core dumping Hello - I am experiencing a situation where apache core dumps. We are using HTML-Mason. The relevant revision numbers are: Apache_1.3.12 mod_perl-1.24 perl-5.6.0 HTML-Mason .87 redhat 6.1 (no patches) Our apache server is built in 2 flavors, one that uses Mason, another that doesn but uses mod_perl. httpd-mason -l reveals Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c whereas httpd-soap (straight mod_perl, but it is used to answer SOAP requests via SOAP.pm) http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c Running a barebonse component (nothing tricky, just loads a normal html component) under Mason causes apache to core dump after a few dozen requests. A stack trace reveals: eading symbols from /lib/libnss_nis.so.2...done. #0 0x8143b34 in Perl_pp_entersub () (gdb) where #0 0x8143b34 in Perl_pp_entersub () #1 0x813aeda in Perl_runops_debug () #2 0x80e4b2f in perl_call_sv () #3 0x80e4780 in perl_call_sv () #4 0x8075aac in perl_call_handler () #5 0x8074fd8 in perl_run_stacked_handlers () #6 0x80726a8 in perl_handler () #7 0x80a0913 in ap_invoke_handler () #8 0x80b3f29 in ap_some_auth_required () #9 0x80b3f8c in ap_process_request () #10 0x80ab82e in ap_child_terminate () #11 0x80ab9bc in ap_child_terminate () #12 0x80abb19 in ap_child_terminate () #13 0x80ac146 in ap_child_terminate () #14 0x80ac8d3 in main () #15 0x400d31eb in __libc_start_main (main=0x80ac58c , argc=2, argv=0xb944, init=0x806286c <_init>, fini=0x81a998c <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:90 (gdb) I've tried building perl and apache and mod_perl with debugging turned on. I can't seem to get more out of the core dump than this. My point in listing the 2 flavors of our apache configurations is that httpd-soap does *not* core whereas the mason server does. Normally I'd just try upgrading but I've hit the latest releases of each piece it seems. I don't know if this will shed any details as to what the problem is. Any help is appreciated. Shane
Core dumping
Title: Core dumping Hello - I am experiencing a situation where apache core dumps. We are using HTML-Mason. The relevant revision numbers are: Apache_1.3.12 mod_perl-1.24 perl-5.6.0 HTML-Mason .87 redhat 6.1 (no patches) Our apache server is built in 2 flavors, one that uses Mason, another that doesn but uses mod_perl. httpd-mason -l reveals Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c whereas httpd-soap (straight mod_perl, but it is used to answer SOAP requests via SOAP.pm) http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c Running a barebonse component (nothing tricky, just loads a normal html component) under Mason causes apache to core dump after a few dozen requests. A stack trace reveals: eading symbols from /lib/libnss_nis.so.2...done. #0 0x8143b34 in Perl_pp_entersub () (gdb) where #0 0x8143b34 in Perl_pp_entersub () #1 0x813aeda in Perl_runops_debug () #2 0x80e4b2f in perl_call_sv () #3 0x80e4780 in perl_call_sv () #4 0x8075aac in perl_call_handler () #5 0x8074fd8 in perl_run_stacked_handlers () #6 0x80726a8 in perl_handler () #7 0x80a0913 in ap_invoke_handler () #8 0x80b3f29 in ap_some_auth_required () #9 0x80b3f8c in ap_process_request () #10 0x80ab82e in ap_child_terminate () #11 0x80ab9bc in ap_child_terminate () #12 0x80abb19 in ap_child_terminate () #13 0x80ac146 in ap_child_terminate () #14 0x80ac8d3 in main () #15 0x400d31eb in __libc_start_main (main=0x80ac58c , argc=2, argv=0xb944, init=0x806286c <_init>, fini=0x81a998c <_fini>, rtld_fini=0x4000a610 <_dl_fini>, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:90 (gdb) I've tried building perl and apache and mod_perl with debugging turned on. I can't seem to get more out of the core dump than this. My point in listing the 2 flavors of our apache configurations is that httpd-soap does *not* core whereas the mason server does. Normally I'd just try upgrading but I've hit the latest releases of each piece it seems. I don't know if this will shed any details as to what the problem is. Any help is appreciated. Shane
