Conor Walsh wrote: > You can trap OOM if your Perl is compiled to use $^M...
http://perldoc.perl.org/perlvar.html $^M By default, running out of memory is an untrappable, fatal error. However, if suitably built, Perl can use the contents of $^M as an emergency memory pool after die()ing. Suppose that your Perl were compiled with -DPERL_EMERGENCY_SBRK and used Perl's malloc. Then 1. $^M = 'a' x (1 << 16); would allocate a 64K buffer for use in an emergency. Interesting. That explanation seems to leave some things unexplained. So presumably with -DPERL_EMERGENCY_SBRK and space allocated to $^M, if an OOM happened you could trap it with $SIG{__DIE__} and have enough heap memory to handle any incidental allocations needed by your signal handler? > ...which your Perl probably isn't. Nope. No PERL_EMERGENCY_SBRK here: Compile-time options: MULTIPLICITY PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_REENTRANT_API or anywhere else in the perl -V output. But looks like it is using Perl's malloc. It's a pain to get the client's IT people to install custom built packages, but I might be able to get a VM setup with a custom build. > Otherwise... if I were you I'd look into a combination > of old-fashioned "sprinkle print statements everywhere"... The code already logs fairly profusely, but the streams from 8 or so child processes are blended together. There is a node-specific identifier prefixed to each line, but the OOM message has no prefix. Eventually the failing process exits with an error code, and the controlling parent notices and identifies the child, so it's theoretically possible to correlate the info. -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
