perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: Trapping SEGV from perl?
Date Thu, 06 Sep 2001 02:33:19 GMT
On Wed, 5 Sep 2001, Doug MacEachern wrote:

> On Wed, 5 Sep 2001, Stas Bekman wrote:
>
> > I was tryint to trap SEGV from the child process that segfaults, but I
> > cannot seem to catch it. I've added this to t/conf/modperl_startup.pl (of
> > course via TestConfigPerl.pm, since the former is autogenerated):
> >
> > use Carp;
> > $SIG{SEGV} = sub { Carp::confess("caught SIGSEGV") };
> > $SIG{ABRT} = sub { Carp::confess("caught SIGABRT") };
> >
> > But the child segfaults with this message in t/logs/error_log:
> >
> > [Wed Sep 05 12:20:07 2001] [notice] child pid 21228 exit signal
> > Segmentation fault (11), possible coredump in
> > /home/stas/apache.org/modperl-2.0/t
> >
> > It seems like Apache handles the SEGV and doesn't propogate it to Perl. I
> > was searching on the google to learn about this issue, but couldn't find
> > anything useful. Your help is appreciated.
>
> well, if apache core dumps before it reaches mod_perl land, that could be
> one reason.

It's clearly in the Perl domain:

#0  0x404af49e in XS_Apache__RequestRec_uri (my_perl=0x82d7d28,
cv=0x8227a40)
    at RequestRec.xs:839
#1  0x40401670 in Perl_pp_entersub (my_perl=0x82d7d28) at pp_hot.c:2715
#2  0x403f70bf in Perl_runops_debug (my_perl=0x82d7d28) at run.c:53
#3  0x4038e380 in S_call_body (my_perl=0x82d7d28, myop=0xbffff5f0,
is_eval=0)
    at perl.c:1851
#4  0x4038df22 in Perl_call_sv (my_perl=0x82d7d28, sv=0x8253fb0, flags=4)
    at perl.c:1769
#5  0x4037ec78 in modperl_callback (my_perl=0x82d7d28, handler=0x815b084,
    p=0x81609fc, s=0x80f4e7c, args=0x825413c) at modperl_callback.c:52
#6  0x4037f337 in modperl_callback_run_handlers (idx=1, type=4,
r=0x8160a2c,
    c=0x0, s=0x80f4e7c, pconf=0x0, plog=0x0, ptemp=0x0)
    at modperl_callback.c:166
#7  0x4037f44e in modperl_callback_per_srv (idx=1, r=0x8160a2c)
    at modperl_callback.c:197
#8  0x403872c0 in modperl_trans_handler (r=0x8160a2c) at
modperl_hooks.c:68
#9  0x080bb417 in ap_run_translate_name (r=0x8160a2c) at request.c:106
#10 0x080bbcfc in ap_process_request_internal (r=0x8160a2c) at
request.c:158
#11 0x080867d1 in ap_process_request (r=0x8160a2c) at http_request.c:284
#12 0x08082d53 in ap_process_http_connection (c=0x8435514) at
http_core.c:287
#13 0x080b34c7 in ap_run_process_connection (c=0x8435514) at
connection.c:82
#14 0x080aa1b6 in child_main (child_num_arg=0) at prefork.c:829
#15 0x080aa2f3 in make_child (s=0x80f4e7c, slot=0) at prefork.c:916

> and if it is Perl that segvs, it is likely the perl runtime is in a
> corrupt state where calling back into Perl simply isn't going to work.

so there is no way to trap such SEGV? I wanted to work on automatic SEGV
trapping and automatically producing the trace, I thought that was a good
example to work with.

_____________________________________________________________________
Stas Bekman              JAm_pH     --   Just Another mod_perl Hacker
http://stason.org/       mod_perl Guide  http://perl.apache.org/guide
mailto:stas@stason.org   http://apachetoday.com http://eXtropia.com/
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message