You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Bruce W. Hoylman" <bh...@advtech.uswest.com> on 2000/09/12 02:24:15 UTC

modperl startup dumps core; trace included

I have a peculiar problem with a modperl module I have written.  When
migrating to the following configuration:

          perl, v5.6.0 built for sun4-solaris
          modperl_20000911162240 (1.2401)
          apache-1.3_20000911161201

If I attempt to load the module in my startup.pl using:

   use Savvy::Moveform ();

the server SIGSEGVs with the following stack trace:

(gdb) set args -X 
(gdb) run
Starting program: /www/sbin/httpd -X
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]

Program received signal SIGSEGV, Segmentation fault.
0xdf81c in Perl_gv_init ()
(gdb) where
#0  0xdf81c in Perl_gv_init ()
#1  0xe0d74 in Perl_gv_fetchpv ()
#2  0x4401c in perl_section_hash_init (name=0x17c848 "Location", dotie=0)
    at perl_config.c:1598
#3  0x4440c in perl_section (parms=0xefffbab0, dummy=0x1c7308, arg=0xefff99ae "")
    at perl_config.c:1701
#4  0xa0a38 in invoke_cmd (cmd=0x1b1540, parms=0xefffbab0, mconfig=0x1c7308, 
    args=0xefff99ae "") at http_config.c:808
#5  0xa1ab0 in ap_handle_command (parms=0xefffbab0, config=0x1c7180, 
    l=0xefff99a8 "<Perl>") at http_config.c:1028
#6  0xa1b90 in ap_srm_command_loop (parms=0xefffbab0, config=0x1c7180)
    at http_config.c:1042
#7  0xa2218 in ap_process_resource_config (s=0x1c6040, 
    fname=0x1c7fc0 "/www/etc/httpd/httpd.conf", p=0x1c6018, ptemp=0x1ce018)
    at http_config.c:1230
#8  0xa2e40 in ap_read_config (p=0x1c6018, ptemp=0x1ce018, 
    confname=0x1b4a60 "etc/httpd/httpd.conf") at http_config.c:1513
#9  0xb1ddc in main (argc=2, argv=0xefffbc84) at http_main.c:4974


The <Perl> section defining the Location directive for the modules is:

$Location{'/Moveform'} = {
   Options => 'FollowSymLinks -Indexes',
   Sethandler => 'perl-script',
   PerlHandler => 'Savvy::Moveform',
   PerlSendHeader => 'Off',

   AuthType => 'Savvy::AuthCookieHandler',
   AuthName => 'AuthCookie',
   PerlAuthenHandler => 'Savvy::AuthCookieHandler->authenticate',
   PerlAuthzHandler => 'Savvy::AuthCookieHandler->authorize',

   require => 'valid_wrkr'
};

Does the trace indicate the Location directive as the culprit?  If so,
it doesn't seem to get too far into it before it bonks.  Suggestions?

This same configuration and module functions as expected using perl
5.005_03 built for sun4-solaris, mod_perl 1.2201, apache-1.3_20000314111200.

Thanks.

Peace.

Re: modperl startup dumps core; trace included

Posted by "Bruce W. Hoylman" <bh...@advtech.uswest.com>.
Rebuilding perl 5.6.0 with the p5p patch solved the SIGSEGV problem.
Thanks for the 'point'.

Peace.

Re: modperl startup dumps core; trace included

Posted by "Bruce W. Hoylman" <bh...@advtech.uswest.com>.
>>>>> "Doug" == Doug MacEachern <do...@covalent.net> writes:

    Doug> looks like one of the 5.6.0 bugs, the Perl patch has been
    Doug> posted here (don't have it handy), here's one that has also
    Doug> helped on the mod_perl side, does it fix the problem for you?

Applying the perl_util.c patch you provided and attempting to load my
module from startup.pl as before results in the same problem.  However
having rebuilt my perl 5.6.0 with '-DDEBUGGING', I get the following
stack trace of the SIGSEGV, with much better symbol output:

Starting program: /www/sbin/httpd -X
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]

Program received signal SIGSEGV, Segmentation fault.
0xdea34 in Perl_gv_init (gv=0x4f1fb0, stash=0x1e3600, name=0x183f28 "Location", 
    len=8, multi=2) at gv.c:106
106         GvFILE(gv) = CopFILE(PL_curcop) ? CopFILE(PL_curcop) : "";
(gdb) where
#0  0xdea34 in Perl_gv_init (gv=0x4f1fb0, stash=0x1e3600, name=0x183f28 "Location", 
    len=8, multi=2) at gv.c:106
#1  0xe0054 in Perl_gv_fetchpv (nambeg=0x183f28 "Location", add=2, sv_type=11)
    at gv.c:681
#2  0x44720 in perl_section_hash_init (name=0x183f28 "Location", dotie=0)
    at perl_config.c:1598
#3  0x44b40 in perl_section (parms=0xefffbab8, dummy=0x1d0d80, arg=0xefff99b6 "")
    at perl_config.c:1701
#4  0xa1120 in invoke_cmd (cmd=0x1bcda0, parms=0xefffbab8, mconfig=0x1d0d80, 
    args=0xefff99b6 "") at http_config.c:808
#5  0xa2198 in ap_handle_command (parms=0xefffbab8, config=0x1d0bf8, 
    l=0xefff99b0 "<Perl>") at http_config.c:1028
#6  0xa2278 in ap_srm_command_loop (parms=0xefffbab8, config=0x1d0bf8)
    at http_config.c:1042
#7  0xa2900 in ap_process_resource_config (s=0x1cfab8, 
    fname=0x1d1a38 "/www/etc/httpd/httpd.conf", p=0x1cfa90, ptemp=0x1d3ac0)
    at http_config.c:1230
#8  0xa3528 in ap_read_config (p=0x1cfa90, ptemp=0x1d3ac0, 
    confname=0x1c02c0 "etc/httpd/httpd.conf") at http_config.c:1513
#9  0xb24c4 in main (argc=2, argv=0xefffbc8c) at http_main.c:4974


Any other ideas?

I will next use the p5p patch you alluded to and see if it has any
effect.  Thanks for your help.

Peace.

Re: modperl startup dumps core; trace included

Posted by Doug MacEachern <do...@covalent.net>.
On Mon, 11 Sep 2000, Bruce W. Hoylman wrote:

> 
> I have a peculiar problem with a modperl module I have written.  When
> migrating to the following configuration:
> 
>           perl, v5.6.0 built for sun4-solaris
>           modperl_20000911162240 (1.2401)
>           apache-1.3_20000911161201
> 
> If I attempt to load the module in my startup.pl using:
> 
>    use Savvy::Moveform ();
> 
> the server SIGSEGVs with the following stack trace:

looks like one of the 5.6.0 bugs, the Perl patch has been posted here
(don't have it handy), here's one that has also helped on the mod_perl
side, does it fix the problem for you?

--- perl_util.c~	Tue Jun 13 10:25:38 2000
+++ perl_util.c	Tue Jun 13 11:16:45 2000
@@ -547,12 +547,14 @@
 {
     dTHR;
     SV *sv = sv_newmortal();
+    COP *old_cop = curcop;
     dTHRCTX;
 
     sv_setpvn(sv, "require ", 8);
     MP_TRACE_d(fprintf(stderr, "loading perl module '%s'...", name)); 
     sv_catpv(sv, name);
     perl_eval_sv(sv, G_DISCARD);
+    curcop = old_cop;
     if(s) {
 	if(perl_eval_ok(s) != OK) {
 	    MP_TRACE_d(fprintf(stderr, "not ok\n"));