Re: Segmentation fault - is Error.pm the culprit?

[Brad Bowman]

 This code essentially worked fine 2 weeks ago but at the time I removed my
 DBI HandleError subroutine. Today when adding it back in I am facing 
 this problem

I had a similar problem with HandleError, see the samples at:
http://bowman.bs/bugs/perl/

I just stopped using HandleError.  It also mysteriously seemed to
be effected by whether or not mod_perl was a dso.  It put it in
perlbug I think.

Brad

-- 
 Intelligence is nothing more than discussing things with others.
 Limitless wisdom comes of this. -- Hagakure

Re: Segmentation fault - is Error.pm the culprit?

[Marcin Kasperski]

Richard Clarke [EMAIL PROTECTED] writes:

 I'm using a subclass of Error.pm to throw exceptions when a DBI
 error happens.  The SEGV only happens after I return SERVER_ERROR
 in response to the thrown and propogated error.

I do not know whether it can be related to your problem but for me
some cryptical problems disappeared when I replaced default Error.pm
with the newer version from CPAN.

Segmentation fault - is Error.pm the culprit?

[Richard Clarke]

I'm using a subclass of Error.pm to throw exceptions when a DBI error
happens.
The SEGV only happens after I return SERVER_ERROR in response to the
thrown and propogated error.
This code essentially worked fine 2 weeks ago but at the time I removed my
DBI HandleError subroutine. Today when adding it back in I am facing this
problem

Running with my debug httpd gives me a backtrace of,

Program received signal SIGSEGV, Segmentation fault.
0x810839d in Perl_sv_setsv ()
(gdb) bt
#0  0x810839d in Perl_sv_setsv ()
#1  0x80ff194 in Perl_pp_sassign ()
#2  0x80fedf6 in Perl_runops_standard ()
#3  0x80c1cd6 in S_call_body ()
#4  0x80c1aba in perl_call_sv ()
#5  0x80c1725 in perl_call_method ()
#6  0x807d458 in perl_call_handler (sv=0x978809c, r=0x97db034, args=0x0) at
mod_perl.c:1655
#7  0x807cbf5 in perl_run_stacked_handlers (hook=0x8147199 PerlHandler,
r=0x97db034, handlers=0x97a4f30) at mod_perl.c:1371
#8  0x807afab in perl_handler (r=0x97db034) at mod_perl.c:897
#9  0x809a841 in ap_invoke_handler (r=0x97db034) at http_config.c:518
#10 0x80afed0 in process_request_internal (r=0x97db034) at
http_request.c:1308
#11 0x80aff3a in ap_process_request (r=0x97db034) at http_request.c:1324
#12 0x80a68ab in child_main (child_num_arg=0) at http_main.c:4603
#13 0x80a6a6d in make_child (s=0x817f034, slot=0, now=1049069980) at
http_main.c:4718
#14 0x80a6be6 in startup_children (number_to_start=50) at http_main.c:4800
#15 0x80a7214 in standalone_main (argc=2, argv=0xbfbffb74) at
http_main.c:5108
#16 0x80a7a74 in main (argc=2, argv=0xbfbffb74) at http_main.c:5456
#17 0x8061f21 in _start ()

For the time being I can use die instead of throw since they are both caught
by my try{} block... this isn't ideal however since I can't identify the
type of exception like this.
Is this likely to be related to Error.pm? Could something else be causing
this? Any advice at all?


This is on,
   mod_perl 1.27, apache 1.3.27, fbsd 4.7-release.

Richard.