Re: Is the Ada run-time required to detect out-of-memory conditions?

["Robert I. Eachus" <rieachus@comcast.net>]

Ludovic Brenta wrote:

> I have received a bug report [1] against GNAT 3.15p and reproduced the
> same behaviour with GCC 3.4.  I would like the advice of language
> lawyers on the issue.
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=250076
> 
> The program allocates memory in an infinite loop using "new" and the
> default storage pool, and of course exhausts all available storage.
> The issue is whether or not Storage_Error should be raised.  With
> GNAT, no exception is raised; instead the program receives SIGKILL
> (not even SIGSEGV) from Linux.
> 
> My first impression is that the program exhausts physical memory (RAM
> + swap) before exhausting the default storage pool, the size of which
> is defined to be the total size of the virtual address space.  As a
> result, the kernel detects the out-of-memory condition before the Ada
> run-time library does, and sends SIGKILL to the program.  Of course,
> the program has no chance to turn SIGKILL into an exception.
> 
> Is my assessment correct?  Is this a bug in the GNAT library?
> 
> Thanks for any insight.
> 
> PS. The original reported says that the program receives SIGSEGV.  He
> uses Linux 2.4.22.  I use 2.4.26 and the program receives SIGKILL
> instead.  I don't know if this is a known change in the kernel's
> behaviour.

Unfortunately you are going to have to determine this for yourself.  Let 
me suggest a program and you can determine what should happen.  But the 
bug as such is not a GNAT library bug, it is an interaction between GNAT 
and Debian.

Write a program that exhausts memory but prints the amount of memory 
allocated and the bounds with each allocation.  You can be smart about 
this, but eventually you may have to have an allocate, write, delay loop 
in the critical area.

My guess is that you will find that what happens is that Debian 
allocates pages but only populates them on write.  So the amount of 
memory allocated eventually exceeds 2**31, even if you don't have 2 Gig 
of paging space.  Now all of a sudden you have a segment of memory 
allocated across the 2 Gig point.  And somewhere along the line some 
code is computing the size of the space allocated by address(Last) - 
address(First).  If this is in fact the case, yes there is a bug, but I 
don't know where.

If you can catch it in the debugger great.  But it sounds like you are 
going to have to figure out from the chunk that is getting allocated 
when the bomb goes off what broke.

Dave Emery used to call Storage_Error a parachute that opens on impact, 
and this is part of why.  Often there is nothing sensible that you can 
do in an local Ada exception handler, you have to try to catch it 
partway down the call stack, if possible.  But usually you are lucky if 
you can catch it inside the program.

-- 

                                           Robert I. Eachus

"The terrorists rejoice in the killing of the innocent, and have 
promised similar violence against Americans, against all free peoples, 
and against any Muslims who reject their ideology of murder. Their 
barbarism cannot be appeased, and their hatred cannot be satisfied. 
There's only one way to deal with terror: We must confront the enemy and 
stay on the offensive until these killers are defeated." -- George W. Bush