You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Grant <em...@gmail.com> on 2006/12/10 16:21:54 UTC

mod_perl-2.0.2 causing segfaults

Hello, I've been dealing with apache2 segfaults on my server for
years.  My consultant thinks it's a mod_perl problem of some sort.
I'm currently using mod_perl-2.0.2.

The segfaults definitely seem to coincide with increases in traffic.
They look like this in error_log:

[Fri Dec 08 09:45:02 2006] [notice] child pid 25294 exit signal
Segmentation fault (11)

and are sometimes accompanied by one of these:

ALERT: bad pipe signal received for /page.html

The ALERT comes from this portion of the Interchange::Link mod_perl module:

sub die_page {

    my $r = shift;
    my $msg;

    warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n";

    $r->content_type ("text/html");
    $r->print (<<EOF);
<html><head><title>Interrupted</title></head>
<body bgcolor="#FFFFFF">
<h3>Someone pressed stop...</h3>
<p>
We have aborted this request because someone terminated it.
Please try again soon.
</p>
</body></html>
EOF

}

Can anyone help me solve this?

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> Are you running on a UNIX or Windows platform?
>
> There was an earlier discussion on mp2 on Windows faulting on
> occassions. Henrik S Hansen gave some insight into the cause of the
> crash, and it seems to point to the Perl dll not being able to release
> memory when it gets too large.

Hello, mod_perl is running on an up-to-date Gentoo Linux system.
Could it be a similar problem though?

- Grant


> > Hello, I've been dealing with apache2 segfaults on my server for
> > years.  My consultant thinks it's a mod_perl problem of some sort.
> > I'm currently using mod_perl-2.0.2.
> >
> > The segfaults definitely seem to coincide with increases in traffic.
> > They look like this in error_log:
> >
> > [Fri Dec 08 09:45:02 2006] [notice] child pid 25294 exit signal
> > Segmentation fault (11)
> >
> > and are sometimes accompanied by one of these:
> >
> > ALERT: bad pipe signal received for /page.html
> >
> > The ALERT comes from this portion of the Interchange::Link mod_perl
> > module:
> >
> > sub die_page {
> >
> >    my $r = shift;
> >    my $msg;
> >
> >    warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n";
> >
> >    $r->content_type ("text/html");
> >    $r->print (<<EOF);
> > <html><head><title>Interrupted</title></head>
> > <body bgcolor="#FFFFFF">
> > <h3>Someone pressed stop...</h3>
> > <p>
> > We have aborted this request because someone terminated it.
> > Please try again soon.
> > </p>
> > </body></html>
> > EOF
> >
> > }
> >
> > Can anyone help me solve this?
> >
> > - Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Foo JH <jh...@extracktor.com>.
Are you running on a UNIX or Windows platform?

There was an earlier discussion on mp2 on Windows faulting on 
occassions. Henrik S Hansen gave some insight into the cause of the 
crash, and it seems to point to the Perl dll not being able to release 
memory when it gets too large.

Grant wrote:
> Hello, I've been dealing with apache2 segfaults on my server for
> years.  My consultant thinks it's a mod_perl problem of some sort.
> I'm currently using mod_perl-2.0.2.
>
> The segfaults definitely seem to coincide with increases in traffic.
> They look like this in error_log:
>
> [Fri Dec 08 09:45:02 2006] [notice] child pid 25294 exit signal
> Segmentation fault (11)
>
> and are sometimes accompanied by one of these:
>
> ALERT: bad pipe signal received for /page.html
>
> The ALERT comes from this portion of the Interchange::Link mod_perl 
> module:
>
> sub die_page {
>
>    my $r = shift;
>    my $msg;
>
>    warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME}\n";
>
>    $r->content_type ("text/html");
>    $r->print (<<EOF);
> <html><head><title>Interrupted</title></head>
> <body bgcolor="#FFFFFF">
> <h3>Someone pressed stop...</h3>
> <p>
> We have aborted this request because someone terminated it.
> Please try again soon.
> </p>
> </body></html>
> EOF
>
> }
>
> Can anyone help me solve this?
>
> - Grant


Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> >> > > > > >   Also, I tried restarting the interchange daemon with
> >> > > > > >   PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> >> > > > > >   frequently.  Does that tell us anything?
> >> > > > >
> >> > > > >
> >> > > > >   It would make sense that, when you have high load, there is a
> >> > > > >   problem
> >> > > > >   processing many concurrent requests which triggers the PIPE
> >> > > > >   signal, so
> >> > > > >   you should find out what the error is, and handle it more
> >> > > > >   gracefully.
> >> > > > >
> >> > > > >   You might want to change the die sub to print out $! and $? -
> >> > > > >   that may
> >> > > > >   give you a bit of a clue as to what caused the PIPE signal.
> >> > > > >
> >> > > > >   I'm guessing (and it is a guess) that the segfaults may be caused
> >> > > > >   because the die sub sends a web response, but that sub could be
> >> > > > >   called
> >> > > > >   while your server is busy doing something else, and the two
> >> > > > >   actions
> >> > > > >   collide.
> >> > > >
> >> > > >   Very good guess.  Commenting out the web response stuff seems to
> >> > > >   have
> >> > > >   eliminated the segfaults.  Adding $! and $? to the warn line, I'm
> >> > > >   getting one of these two bits along with each ALERT now:
> >> > > >
> >> > > >   Broken pipe 0
> >> > > >   Inappropriate ioctl for device 0
> >> > >  This could happen from a Cntrl-C or stop in a browser.
> >> > >
> >> > >  Add
> >> > >  require Carp;
> >> > >  Carp::cluck() to your die() function.
> >> >
> >> >  Is this someplace that checking $r->connection->aborted() would be
> >> >  useful?
> >>
> >>  Would I just add "$r->connection->aborted()" without the quotes to the
> >>  warn line?
> >
> > If I do change the warn line to:
> >
> > warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} $! $?
> > $r->connection->aborted()\n";
>
> try
>
>    warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} $! $? "
>        . $r->connection->aborted . "\n";

I'm getting the same message in error_log as before, except appended
with a "1".  However, segfaults have returned which is very strange.

- Grant


> > I get:
> >
> > ALERT: bad pipe signal received for / Broken pipe 0
> > Apache2::RequestRec=SCALAR(0x16eef638)->connection->aborted()
> >
> > Any help with that or Carp::cluck implementation would be greatly
> > appreciated.

Re: mod_perl-2.0.2 causing segfaults

Posted by Fred Moyer <fr...@taperfriendlymusic.org>.
On Mon, 11 Dec 2006, Grant wrote:

>> > > > > >   Also, I tried restarting the interchange daemon with
>> > > > > >   PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
>> > > > > >   frequently.  Does that tell us anything?
>> > > > > 
>> > > > > 
>> > > > >   It would make sense that, when you have high load, there is a 
>> > > > >   problem
>> > > > >   processing many concurrent requests which triggers the PIPE 
>> > > > >   signal, so
>> > > > >   you should find out what the error is, and handle it more 
>> > > > >   gracefully.
>> > > > > 
>> > > > >   You might want to change the die sub to print out $! and $? - 
>> > > > >   that may
>> > > > >   give you a bit of a clue as to what caused the PIPE signal.
>> > > > > 
>> > > > >   I'm guessing (and it is a guess) that the segfaults may be caused
>> > > > >   because the die sub sends a web response, but that sub could be 
>> > > > >   called
>> > > > >   while your server is busy doing something else, and the two 
>> > > > >   actions
>> > > > >   collide.
>> > > > 
>> > > >   Very good guess.  Commenting out the web response stuff seems to 
>> > > >   have
>> > > >   eliminated the segfaults.  Adding $! and $? to the warn line, I'm
>> > > >   getting one of these two bits along with each ALERT now:
>> > > > 
>> > > >   Broken pipe 0
>> > > >   Inappropriate ioctl for device 0
>> > >  This could happen from a Cntrl-C or stop in a browser.
>> > > 
>> > >  Add
>> > >  require Carp;
>> > >  Carp::cluck() to your die() function.
>> > 
>> >  Is this someplace that checking $r->connection->aborted() would be 
>> >  useful?
>>
>>  Would I just add "$r->connection->aborted()" without the quotes to the
>>  warn line?
>
> If I do change the warn line to:
>
> warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} $! $?
> $r->connection->aborted()\n";

try

   warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} $! $? "
       . $r->connection->aborted . "\n";

>
> I get:
>
> ALERT: bad pipe signal received for / Broken pipe 0
> Apache2::RequestRec=SCALAR(0x16eef638)->connection->aborted()
>
> Any help with that or Carp::cluck implementation would be greatly 
> appreciated.
>
> - Grant
>

Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> > >> > >  Also, I tried restarting the interchange daemon with
> > >> > >  PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> > >> > >  frequently.  Does that tell us anything?
> > >> >
> > >> >
> > >> >  It would make sense that, when you have high load, there is a problem
> > >> >  processing many concurrent requests which triggers the PIPE signal, so
> > >> >  you should find out what the error is, and handle it more gracefully.
> > >> >
> > >> >  You might want to change the die sub to print out $! and $? - that may
> > >> >  give you a bit of a clue as to what caused the PIPE signal.
> > >> >
> > >> >  I'm guessing (and it is a guess) that the segfaults may be caused
> > >> >  because the die sub sends a web response, but that sub could be called
> > >> >  while your server is busy doing something else, and the two actions
> > >> >  collide.
> > >>
> > >>  Very good guess.  Commenting out the web response stuff seems to have
> > >>  eliminated the segfaults.  Adding $! and $? to the warn line, I'm
> > >>  getting one of these two bits along with each ALERT now:
> > >>
> > >>  Broken pipe 0
> > >>  Inappropriate ioctl for device 0
> > > This could happen from a Cntrl-C or stop in a browser.
> > >
> > > Add
> > > require Carp;
> > > Carp::cluck() to your die() function.
> >
> > Is this someplace that checking $r->connection->aborted() would be useful?
>
> Would I just add "$r->connection->aborted()" without the quotes to the
> warn line?

If I do change the warn line to:

warn "ALERT: bad pipe signal received for $ENV{SCRIPT_NAME} $! $?
$r->connection->aborted()\n";

I get:

ALERT: bad pipe signal received for / Broken pipe 0
Apache2::RequestRec=SCALAR(0x16eef638)->connection->aborted()

Any help with that or Carp::cluck implementation would be greatly appreciated.

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> >> > >  Also, I tried restarting the interchange daemon with
> >> > >  PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> >> > >  frequently.  Does that tell us anything?
> >> >
> >> >
> >> >  It would make sense that, when you have high load, there is a problem
> >> >  processing many concurrent requests which triggers the PIPE signal, so
> >> >  you should find out what the error is, and handle it more gracefully.
> >> >
> >> >  You might want to change the die sub to print out $! and $? - that may
> >> >  give you a bit of a clue as to what caused the PIPE signal.
> >> >
> >> >  I'm guessing (and it is a guess) that the segfaults may be caused
> >> >  because the die sub sends a web response, but that sub could be called
> >> >  while your server is busy doing something else, and the two actions
> >> >  collide.
> >>
> >>  Very good guess.  Commenting out the web response stuff seems to have
> >>  eliminated the segfaults.  Adding $! and $? to the warn line, I'm
> >>  getting one of these two bits along with each ALERT now:
> >>
> >>  Broken pipe 0
> >>  Inappropriate ioctl for device 0
> > This could happen from a Cntrl-C or stop in a browser.
> >
> > Add
> > require Carp;
> > Carp::cluck() to your die() function.
>
> Is this someplace that checking $r->connection->aborted() would be useful?

Would I just add "$r->connection->aborted()" without the quotes to the
warn line?

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> >> > The way my config works, apache2 hands all requests to the interchange
> >> > (icdevgroup.org) daemon via a socket by way of the mod_perl module
> >> > (Interchange::Link).
> >> >
> >> > So the error is caused by the mod_perl module trying to read or write
> >> > to or from the interchange daemon and failing?  If that's correct, it
> >> > sounds like the next thing to do is find out why it's failing?  Can it
> >> > be said whether it's a problem with mod_perl, Interchange::Link,
> >> > interchange, or something else at this point?
> >> >
> >> > Also, I tried restarting the interchange daemon with
> >> > PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> >> > frequently.  Does that tell us anything?
> >>
> >>
> >> It would make sense that, when you have high load, there is a problem
> >> processing many concurrent requests which triggers the PIPE signal, so
> >> you should find out what the error is, and handle it more gracefully.
> >>
> >> You might want to change the die sub to print out $! and $? - that may
> >> give you a bit of a clue as to what caused the PIPE signal.
> >>
> >> I'm guessing (and it is a guess) that the segfaults may be caused
> >> because the die sub sends a web response, but that sub could be called
> >> while your server is busy doing something else, and the two actions
> >> collide.
> >
> > Very good guess.  Commenting out the web response stuff seems to have
> > eliminated the segfaults.  Adding $! and $? to the warn line, I'm
> > getting one of these two bits along with each ALERT now:
> >
> > Broken pipe 0
> > Inappropriate ioctl for device 0
> This could happen from a Cntrl-C or stop in a browser.

It happens to me quite a bit as I browse my own site and I'm not
hitting the stop button.

> Add
> require Carp;
> Carp::cluck() to your die() function.

I should add:

require Carp;

to the top of the module with the other requires, and:

Carp::cluck()

on it's own line right before the warn line that includes the ALERT?

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Fred Moyer <fr...@redhotpenguin.com>.
On Mon, 11 Dec 2006, Philip M. Gollucci wrote:

> Grant wrote:
>> > >  Also, I tried restarting the interchange daemon with
>> > >  PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
>> > >  frequently.  Does that tell us anything?
>> > 
>> > 
>> >  It would make sense that, when you have high load, there is a problem
>> >  processing many concurrent requests which triggers the PIPE signal, so
>> >  you should find out what the error is, and handle it more gracefully.
>> > 
>> >  You might want to change the die sub to print out $! and $? - that may
>> >  give you a bit of a clue as to what caused the PIPE signal.
>> > 
>> >  I'm guessing (and it is a guess) that the segfaults may be caused
>> >  because the die sub sends a web response, but that sub could be called
>> >  while your server is busy doing something else, and the two actions
>> >  collide.
>>
>>  Very good guess.  Commenting out the web response stuff seems to have
>>  eliminated the segfaults.  Adding $! and $? to the warn line, I'm
>>  getting one of these two bits along with each ALERT now:
>>
>>  Broken pipe 0
>>  Inappropriate ioctl for device 0
> This could happen from a Cntrl-C or stop in a browser.
>
> Add
> require Carp;
> Carp::cluck() to your die() function.

Is this someplace that checking $r->connection->aborted() would be useful?

Re: mod_perl-2.0.2 causing segfaults

Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Grant wrote:
>> > The way my config works, apache2 hands all requests to the interchange
>> > (icdevgroup.org) daemon via a socket by way of the mod_perl module
>> > (Interchange::Link).
>> >
>> > So the error is caused by the mod_perl module trying to read or write
>> > to or from the interchange daemon and failing?  If that's correct, it
>> > sounds like the next thing to do is find out why it's failing?  Can it
>> > be said whether it's a problem with mod_perl, Interchange::Link,
>> > interchange, or something else at this point?
>> >
>> > Also, I tried restarting the interchange daemon with
>> > PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
>> > frequently.  Does that tell us anything?
>>
>>
>> It would make sense that, when you have high load, there is a problem
>> processing many concurrent requests which triggers the PIPE signal, so
>> you should find out what the error is, and handle it more gracefully.
>>
>> You might want to change the die sub to print out $! and $? - that may
>> give you a bit of a clue as to what caused the PIPE signal.
>>
>> I'm guessing (and it is a guess) that the segfaults may be caused
>> because the die sub sends a web response, but that sub could be called
>> while your server is busy doing something else, and the two actions
>> collide.
> 
> Very good guess.  Commenting out the web response stuff seems to have
> eliminated the segfaults.  Adding $! and $? to the warn line, I'm
> getting one of these two bits along with each ALERT now:
> 
> Broken pipe 0
> Inappropriate ioctl for device 0
This could happen from a Cntrl-C or stop in a browser.

Add
require Carp;
Carp::cluck() to your die() function.


-- 
------------------------------------------------------------------------
Philip M. Gollucci (pgollucci@p6m7g8.com) 323.219.4708
Consultant / http://p6m7g8.net/Resume/resume.shtml
Senior Software Engineer - TicketMaster - http://ticketmaster.com
1024D/EC88A0BF 0DE5 C55C 6BF3 B235 2DAB  B89E 1324 9B4F EC88 A0BF

I never had a dream come true
'Til the day that I found you.
Even though I pretend that I've moved on
You'll always be my baby.
I never found the words to say
You're the one I think about each day
And I know no matter where life takes me to
A part of me will always be...
A part of me will always be with you.

Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> > The way my config works, apache2 hands all requests to the interchange
> > (icdevgroup.org) daemon via a socket by way of the mod_perl module
> > (Interchange::Link).
> >
> > So the error is caused by the mod_perl module trying to read or write
> > to or from the interchange daemon and failing?  If that's correct, it
> > sounds like the next thing to do is find out why it's failing?  Can it
> > be said whether it's a problem with mod_perl, Interchange::Link,
> > interchange, or something else at this point?
> >
> > Also, I tried restarting the interchange daemon with
> > PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> > frequently.  Does that tell us anything?
>
>
> It would make sense that, when you have high load, there is a problem
> processing many concurrent requests which triggers the PIPE signal, so
> you should find out what the error is, and handle it more gracefully.
>
> You might want to change the die sub to print out $! and $? - that may
> give you a bit of a clue as to what caused the PIPE signal.
>
> I'm guessing (and it is a guess) that the segfaults may be caused
> because the die sub sends a web response, but that sub could be called
> while your server is busy doing something else, and the two actions
> collide.

Very good guess.  Commenting out the web response stuff seems to have
eliminated the segfaults.  Adding $! and $? to the warn line, I'm
getting one of these two bits along with each ALERT now:

Broken pipe 0
Inappropriate ioctl for device 0

Any ideas?

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> > The way my config works, apache2 hands all requests to the interchange
> > (icdevgroup.org) daemon via a socket by way of the mod_perl module
> > (Interchange::Link).
> >
> > So the error is caused by the mod_perl module trying to read or write
> > to or from the interchange daemon and failing?  If that's correct, it
> > sounds like the next thing to do is find out why it's failing?  Can it
> > be said whether it's a problem with mod_perl, Interchange::Link,
> > interchange, or something else at this point?
> >
> > Also, I tried restarting the interchange daemon with
> > PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> > frequently.  Does that tell us anything?
>
>
> It would make sense that, when you have high load, there is a problem
> processing many concurrent requests which triggers the PIPE signal, so
> you should find out what the error is, and handle it more gracefully.
>
> You might want to change the die sub to print out $! and $? - that may
> give you a bit of a clue as to what caused the PIPE signal.
>
> I'm guessing (and it is a guess) that the segfaults may be caused
> because the die sub sends a web response, but that sub could be called
> while your server is busy doing something else, and the two actions
> collide.

There also seems to be some kind of a cumulative effect here.  If I
refresh one of my pages over and over, my error_log is filled with
ALERTs pertaining to that page.  After that, the ALERTs show up much
more frequently from normal traffic until apache2 is restarted.

Could this problem have something to do with memory?  I see that my
memory usage drops significantly as apache2 is restarted.

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Clinton Gormley <cl...@traveljury.com>.
> The way my config works, apache2 hands all requests to the interchange
> (icdevgroup.org) daemon via a socket by way of the mod_perl module
> (Interchange::Link).
> 
> So the error is caused by the mod_perl module trying to read or write
> to or from the interchange daemon and failing?  If that's correct, it
> sounds like the next thing to do is find out why it's failing?  Can it
> be said whether it's a problem with mod_perl, Interchange::Link,
> interchange, or something else at this point?
> 
> Also, I tried restarting the interchange daemon with
> PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
> frequently.  Does that tell us anything?


It would make sense that, when you have high load, there is a problem
processing many concurrent requests which triggers the PIPE signal, so
you should find out what the error is, and handle it more gracefully.

You might want to change the die sub to print out $! and $? - that may
give you a bit of a clue as to what caused the PIPE signal.

I'm guessing (and it is a guess) that the segfaults may be caused
because the die sub sends a web response, but that sub could be called
while your server is busy doing something else, and the two actions
collide.

clint
> 
> - Grant

________________________________________________________________________

Clinton Gormley clinton@traveljury.com

www.TravelJury.com - For travellers, By travellers




Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> > Actually, the only place die_page is called in the module is:
> >
> > $SIG{PIPE} = sub { die_page($r); };
> >
> > What does that mean?
>
> Have a look here:
> http://perldoc.perl.org/perlipc.html#Using-open()-for-IPC
>
> There is an error reading from or writing to a pipe.

The way my config works, apache2 hands all requests to the interchange
(icdevgroup.org) daemon via a socket by way of the mod_perl module
(Interchange::Link).

So the error is caused by the mod_perl module trying to read or write
to or from the interchange daemon and failing?  If that's correct, it
sounds like the next thing to do is find out why it's failing?  Can it
be said whether it's a problem with mod_perl, Interchange::Link,
interchange, or something else at this point?

Also, I tried restarting the interchange daemon with
PERL_SIGNALS=unsafe and the ALERT/segfaults came MUCH MUCH more
frequently.  Does that tell us anything?

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Clinton Gormley <cl...@traveljury.com>.
> Actually, the only place die_page is called in the module is:
> 
> $SIG{PIPE} = sub { die_page($r); };
> 
> What does that mean?

Have a look here:
http://perldoc.perl.org/perlipc.html#Using-open()-for-IPC

There is an error reading from or writing to a pipe.

> 
> - Grant

________________________________________________________________________

Clinton Gormley clinton@traveljury.com

www.TravelJury.com - For travellers, By travellers




Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> >> you need to find out why die_page is  being called.
> >
> > Do you have any advice on the best way to do that?
>
> You could start by using caller():
>     my ($package, $filename, $line) = caller;
> within the sub, in order to see where it's being
> called from.

Actually, the only place die_page is called in the module is:

$SIG{PIPE} = sub { die_page($r); };

What does that mean?

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 10 Dec 2006, Grant wrote:
[ ... ]
>> you need to find out why die_page is  being called.
>
> Do you have any advice on the best way to do that?

You could start by using caller():
    my ($package, $filename, $line) = caller;
within the sub, in order to see where it's being
called from.

-- 
best regards,
Randy Kobes

Re: mod_perl-2.0.2 causing segfaults

Posted by Grant <em...@gmail.com>.
> > and are sometimes accompanied by one of these:
> >
> > ALERT: bad pipe signal received for /page.html
> >
> > The ALERT comes from this portion of the Interchange::Link mod_perl
> > module:
> >
> > sub die_page {
>
> you need to find out why die_page is  being called.

Do you have any advice on the best way to do that?

- Grant

Re: mod_perl-2.0.2 causing segfaults

Posted by Jonathan Vanasco <mo...@2xlp.com>.
On Dec 10, 2006, at 10:21 AM, Grant wrote:

> and are sometimes accompanied by one of these:
>
> ALERT: bad pipe signal received for /page.html
>
> The ALERT comes from this portion of the Interchange::Link mod_perl  
> module:
>
> sub die_page {

you need to find out why die_page is  being called.



// Jonathan Vanasco

| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - - - - - - - - -