perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ali ISIK <fenlis...@gmail.com>
Subject Re: [mp2] repeatable segfault at ap_get_module_config
Date Fri, 21 Oct 2005 15:11:50 GMT
Philippe,

Thank you for your help.  Please find the gdb
output below.  m doesn't seem to point to
anything.

Here is some more information that may be relevant.

(1) The segfault seems to happen *after* the http session
is complete, perhaps during some destroy/garbage-collect
sequence.  That is, the browser gets what it asks for.
If you have tens of server children, the user does not
feel that anything is amiss.

(2) When I configure the /perl/ directory to be the
equivalent of /cgi-bin/ (ScriptAlias), all seems to
be fine; no error messages in the log.

(3) here is the end of http.conf:
===========================================
LoadModule perl_module modules/mod_perl.so

<Directory "/usr/local/apache2/perl">
        AllowOverride None
        Order allow,deny
        Allow from all
</Directory>

PerlModule ModPerl::Registry
Alias /perl/ /usr/local/apache2/perl/
<Location /perl/>
        SetHandler perl-script
        PerlResponseHandler ModPerl::Registry
        PerlOptions +ParseHeaders
        Options +ExecCGI
</Location>

PerlSwitches -wT
#PerlTrace all

CoreDumpDirectory /tmp
==========================================

On 10/21/05, Philippe M. Chiasson <gozer@ectoplasm.org> wrote:
> Ali ISIK wrote:
> > -------------8<---------- Start Bug Report ------------8<----------
> > 1. Problem Description:
> >
> > I am building a web application with a Postgres backend using
> > Class::DBI.  Some scripts generate repeatable Segmentation
> > Faults on their second invocation.  I tried compiling everything
> > with cc and then compiling everything with gcc.  Still the same
> > segfaults.  Perl, Apache, mod_perl and the CPAN modules are
> > all the latest stable versions.
>
> Any chance at reducing these scripts to a short example that causes
> this bug ?
>

There are so many modules that you would curse at me
if I sent you all that stuff.  I can create a tarball of the
used modules and send that as an attachment, but
even that would require some work, as I would like
to reduce the info-noise as much as possible.
Please tell me if you would like this.

> > [...]
> >
> > 3. This is the core dump trace: (if you get a core dump):
> >
> > (gdb) where
> > #0  ap_get_module_config (cv=0x30303320, m=0x30303320) at util_debug.c:106
> > #1  0x40331f30 in Perl_pp_entersub () at pp_hot.c:2888
> > #2  0x40314b9d in Perl_runops_debug () at dump.c:1452
> > #3  0x402c48fa in S_call_body (myop=0xbfffeea0, is_eval=0) at perl.c:2364
> > #4  0x402c4577 in Perl_call_sv (sv=0x8173398, flags=4) at perl.c:2282
> > #5  0x402a7303 in modperl_callback (handler=0x8130b30, p=0x825f880,
> > r=0x825f8b8, s=0x80bd848, args=0x8777914)
> >     at modperl_callback.c:100
> > #6  0x402a7a0e in modperl_callback_run_handlers (idx=6, type=4,
> > r=0x825f8b8, c=0x0, s=0x80bd848, pconf=0x0, plog=0x0, ptemp=0x0,
> >     run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:261
> > #7  0x402a7de5 in modperl_callback_per_dir (idx=6, r=0x825f8b8,
> > run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:368
> > #8  0x402a34ee in modperl_response_handler_run (r=0x825f8b8, finish=0)
> > at mod_perl.c:979
> > #9  0x402a379b in modperl_response_handler_cgi (r=0x825f8b8) at mod_perl.c:1074
> > #10 0x0807eafb in ap_run_handler (r=0x825f8b8) at config.c:152
> > #11 0x08081535 in ap_invoke_handler (r=0x825f8b8) at config.c:364
> > #12 0x0806e0df in ap_process_request (r=0x825f8b8) at http_request.c:249
> > #13 0x08069669 in ap_process_http_connection (c=0x8257970) at http_core.c:251
> > #14 0x08088acb in ap_run_process_connection (c=0x8257970) at connection.c:43
> > #15 0x0807dc08 in child_main (child_num_arg=<value optimized out>) at
> > prefork.c:610
> > #16 0x0807dd91 in make_child (s=<value optimized out>, slot=0) at prefork.c:704
> > #17 0x0807de21 in startup_children (number_to_start=5) at prefork.c:722
> > #18 0x0807e4ed in ap_mpm_run (_pconf=0x80b90a8, plog=0x80f1188,
> > s=0x80bd848) at prefork.c:941
> > #19 0x080836fc in main (argc=3, argv=0xbffff444) at main.c:618
> > (gdb) define curinfo
> > Type commands for definition of "curinfo".
> > End with a line saying just "end".
> >
> >>    printf "%d:%s\n", PL_curcop->cop_line, \
> >
> >      ((XPV*)(*(XPVGV*)PL_curcop->cop_filegv->sv_any)\
> >      ->xgv_gp->gp_sv->sv_any)->xpv_pv
> >
> >> end
> >
> > (gdb) curinfo
> > 62:(eval 26)
> > (gdb)
>
> Can you :
>
> (gdb) print *m
> (gdb) print *cv
>
> ?

(gdb) run -X
Starting program: /usr/local/apache2/bin/httpd -X
[Thread debugging using libthread_db enabled]
[New Thread 1076002208 (LWP 18474)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076002208 (LWP 18474)]
ap_get_module_config (cv=0x2, m=0x2) at util_debug.c:106
106         return ((void **)cv)[m->module_index];

(gdb) print *m
Cannot access memory at address 0x2

(gdb) print *cv
$1 = <incomplete type>


Ali ISIK

Mime
View raw message