I too followed the advice too, but it did nothing but lead my down the wrong path. The advice should be updated.

My point is that $^M does absolutely nothing unless you use perl's malloc, which isn't true for most common perl installations these days. compiling with PERL_EMERGENCY_SBRK doesn't help either because it's the default if you usemymalloc, and useless if you don't You MUST compile perl with "-Dusemymalloc=y". A simple grep in the perl hints directory shows that many popular systems such as linux, freebsd and openbsd default to the system malloc which disables the functionality of $^M.

I'd simply like to see the documentation updated, and I'm happy to do it. I know it would have saved me hours and hours of headaches. The documentation as it stands now is misleading.

of course if you use perl's malloc, the advice helps.

I'd still like to know why mod_perl can get into an infinite loop writtitng "Callback called exit". In perl.c, when that happens my_exit_jump(); is called which should presumably exit the process, but somehow that doesn't happen and some sort of infinite loop occurs outside of my code that fills the log of with gigibytes of 'Callback called exit' messages.


regards,

brian

On May 5, 2004, at 11:00 PM, Glenn wrote:

On Wed, May 05, 2004 at 08:11:56PM -0600, Brian Hirt wrote:
I've been running across a problem lately where a child process
terminates because of an out of memory error. It prints Out of Memory
once, the the process sucks up all available cpu print "Callback called
exit." to the log file until it hit's it's 2GB max size.


I have some Apache::Resource limits set, and they probably need to be
raised, but the way the error is handled is not very graceful.  I'd
expect the child to just terminate after reporting the first error
message.   I'm not sure if this is a perl problem or a mod_perl
problem.   I'd still like to figure out how to prevent the repeating
message from happening.

Anyway, I've been pulling my hair out trying to prevent this, and I've
finally figured out how to trap this. I have some suggestions for the
documentation, because the following url could use some help:


http://perl.apache.org/docs/1.0/guide/ troubleshooting.html#Callback_called_exit

I've followed that advice and explicitly allocated memory into $^M. I have the following in my mod_perl_startup.pl, which I run from httpd.conf with PerlRequire /path/to/mod_perl_startup.pl If 64K is not enough for you, try increasing the allocation.

Cheers,
Glenn

use strict;

## ----------
## ----------

## This section is similar in scope to Apache::Debug.
## Delivers a stack backtrace to the error log when perl code dies.

## Allocate 64K as an emergency memory pool for use in out of memory situation
$^M = 0x00 x 65536;


## Little trick to initialize this routine here so that in the case of OOM,
## compiling this routine doesn't eat memory from the emergency memory pool $^M
use CGI::Carp ();
eval { CGI::Carp::confess('init') };


## Importing CGI::Carp sets $main::SIG{__DIE__} = \&CGI::Carp::die;
## Override that to additionally give a stack backtrace
$main::SIG{__DIE__} = \&CGI::Carp::confess;

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html



Reply via email to