I've found

if (my $chld = fork) {
   # supervise $chld from here 
} 
else { 
   # unreliable process here
}
[download]

Edit: Maybe you can make do with just confirming a successful run with a print "successfully done\n";

Thanks! Not quite sure how I failed to think of the simple approach of printing "OK" or some such at the end, then checking for presence/absence of that, but that will do me fine in this instance. Pointing out the obvious is much appreciated!

Should anyone be interested, the error appears to be on line 108 of vmem.h (5.8.8 sources):

Disassembly of Function perl58.dll!VMem::LinkBlock (0x280EED69)

  ; protected:
  ; #ifdef _USE_LINKED_LIST
  ;     void LinkBlock(PMEMORY_BLOCK_HEADER ptr)
  ;     {
  0x280EED69: PUSH     EBP                                
  0x280EED6A: MOV      EBP,ESP                            
  0x280EED6C: PUSH     ECX                                
  0x280EED6D: PUSH     ECX                                
  0x280EED6E: MOV      DWORD PTR [EBP-0x8],ECX            ; VAR:this <
+VMem *>
  ; vmem.h - Line 106
  ;     PMEMORY_BLOCK_HEADER next = m_Dummy.pNext;
  0x280EED71: MOV      EAX,DWORD PTR [EBP-0x8]            ; VAR:this <
+VMem *>
  0x280EED74: MOV      EAX,DWORD PTR [EAX+0x4]            
  0x280EED77: MOV      DWORD PTR [EBP-0x4],EAX            ; VAR:next <
+_MemoryBlockHeader *>
  ; vmem.h - Line 107
  ;     m_Dummy.pNext = ptr;
  0x280EED7A: MOV      EAX,DWORD PTR [EBP-0x8]            ; VAR:this <
+VMem *>
  0x280EED7D: MOV      ECX,DWORD PTR [EBP+0x8]            ; ARG:ptr <_
+MemoryBlockHeader *>
  0x280EED80: MOV      DWORD PTR [EAX+0x4],ECX            
  ; vmem.h - Line 108
  ;     ptr->pPrev = &m_Dummy;
  0x280EED83: MOV      EAX,DWORD PTR [EBP-0x8]            ; VAR:this <
+VMem *>
  0x280EED86: ADD      EAX,0x4                            
  0x280EED89: MOV      ECX,DWORD PTR [EBP+0x8]            ; ARG:ptr <_
+MemoryBlockHeader *>

### TRAP OCCURS HERE ###### TRAP OCCURS HERE ###### TRAP OCCURS HERE #
+##

+ 0x280EED8C: MOV      DWORD PTR [ECX+0x4],EAX           

### TRAP OCCURS HERE ###### TRAP OCCURS HERE ###### TRAP OCCURS HERE #
+##
 
  ; vmem.h - Line 109
  ;     ptr->pNext = next;
  0x280EED8F: MOV      EAX,DWORD PTR [EBP+0x8]            ; ARG:ptr <_
+MemoryBlockHeader *>
  0x280EED92: MOV      ECX,DWORD PTR [EBP-0x4]            ; VAR:next <
+_MemoryBlockHeader *>
  0x280EED95: MOV      DWORD PTR [EAX],ECX                
  ; vmem.h - Line 110
  ;         ptr->owner = this;
  0x280EED97: MOV      EAX,DWORD PTR [EBP+0x8]            ; ARG:ptr <_
+MemoryBlockHeader *>
  0x280EED9A: MOV      ECX,DWORD PTR [EBP-0x8]            ; VAR:this <
+VMem *>
  0x280EED9D: MOV      DWORD PTR [EAX+0x8],ECX            
  ; vmem.h - Line 111
  ;     next->pPrev = ptr;
  0x280EEDA0: MOV      EAX,DWORD PTR [EBP-0x4]            ; VAR:next <
+_MemoryBlockHeader *>
  0x280EEDA3: MOV      ECX,DWORD PTR [EBP+0x8]            ; ARG:ptr <_
+MemoryBlockHeader *>
  0x280EEDA6: MOV      DWORD PTR [EAX+0x4],ECX            
  ; vmem.h - Line 112
  ;     }
  0x280EEDA9: LEAVE                                       
  0x280EEDAA: RET      0x4                                
  ;*******************************************************************
+*************
[download]

BrowserUk:

So LinkBlock didn't verify the pointer was valid before trying to link it into the list?

...roboticus

To be honest, I can't work out how it gets in there. The 100+ *alloc macros and functions in the Perl sources make it impossible to work out what is going on at the source level.

And the use of C++ (style) classes for odd bits of the code, with runtime built dispatch tables throws my debugger's stack trace into loops. That means I can't follow it in that way. I can only tell you where it appears to be trapping.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

You could take a look a Is $^M a leftover April Fool? and see if you can glean anything useful, because I didn't.

Back then, probably 5.6.1 going by the dates, it at least did issue the 'Out of memory' error on Win32. Since 5.8.something, possibly 0, it has stopped even giving that comfort.

$ perl OOM.pl
Segmentation fault (core dumped)

$ cat OOM.pl
#!/usr/bin/perl -w
use strict;
use warnings;

my %hash;
my $count;

$hash{$count++} = 'xyz'x999 while (1);
[download]

...roboticus

It took me about three hours to figure out what the problem was. An error or warning would have helped. I am used to silly warnings about deep recursion. Running out of memory should rate at least a warning.

I expect this problem to get worse as the limitations of 32 bit systems become increasingly confining.

When I made a test program for exhausting memory, I got a helpful error message, "Out of Memory!" I have gotten the same helpful message when I ran out of memory due to a program bug. I think the problem of silent memory-induced process death is a problem only in certain scenarios.