From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ab4f67f984ef04f9
X-Google-Attributes: gid103376,public
Path: 
 controlnews3.google.com!news2.google.com!news.maxwell.syr.edu!newsfeed1.ip.tiscali.net!tiscali!transit1.news.tiscali.nl!dreader2.news.tiscali.nl!not-for-mail
Newsgroups: comp.lang.ada
Cc: 250076@bugs.debian.org
Subject: Re: Is the Ada run-time required to detect out-of-memory
 conditions?
References: <878yfmiuak.fsf@insalien.org>
 <5ad0dd8a.0405210313.70f9339d@posting.google.com>
 <1486434.Nr7pvG7a0e@linux1.krischik.com>
 <3YmdnQbGo7stujPd4p2dnA@comcast.com>
From: Ludovic Brenta <ludovic.brenta@insalien.org>
Date: Fri, 21 May 2004 19:13:36 +0200
Message-ID: <87vfipputb.fsf@insalien.org>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
Cancel-Lock: sha1:TWpZdj9dKFA0+ap7hKLCKmdvZh0=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Organization: Tiscali bv
NNTP-Posting-Date: 21 May 2004 19:12:29 CEST
NNTP-Posting-Host: 83.134.238.201
X-Trace: 1085159549 dreader2.news.tiscali.nl 41760 83.134.238.201:34764
X-Complaints-To: abuse@tiscali.nl
Xref: controlnews3.google.com comp.lang.ada:750
Date: 2004-05-21T19:12:29+02:00
List-Id: <comp.lang.ada>

Here are some more data points that seem to confirm my initial
assessment.  The process was killed by the kernel when I had 256 MiB
of RAM and 256 MiB of swap.  I created additional swap files so I now
have 256 MiB RAM and 4 GiB swap.  I now get a Storage_Error after
approximately 192 million iterations.
Ada.Exceptions.Exception_Information outputs:

Exception name: STORAGE_ERROR
Message: heap exhausted

Here is the backtrace at the point where the exception is raised:

(gdb) bt
#0  0x40091950 in __gnat_raise_nodefer_with_msg ()
   from /usr/lib/libgnat-3.15p.so.1
#1  0x40091d18 in __gnat_raise_with_msg () from /usr/lib/libgnat-3.15p.so.1
#2  0x40091ab2 in __gnat_raise_exception () from /usr/lib/libgnat-3.15p.so.1
#3  0x40191e3b in __gnat_malloc () from /usr/lib/libgnat-3.15p.so.1
#4  0x08049a27 in test_250076 () at test_250076.adb:13
#5  0x0804978d in main (argc=1, argv=(system.address) 0xbffffce4, 
    envp=(system.address) 0xbffffcec) at b~test_250076.adb:168
#6  0x401cddc6 in __libc_start_main () from /lib/libc.so.6

`top' indicates that the process takes 2940 MiB of virtual memory.  I
think that virtual memory has indeed been exhausted; the limit is 3072
MiB (3 GiB) for all user-space programs, with 1 GiB reserved for the
kernel.

Now, 2940 MiB / 192_650_250 iterations averages 16 bytes per
allocation.  Each Integer is theoretically only 4 bytes.  So, while
libgnat does indeed reuse previously allocated pages, there is a
non-negligible overhead.  Part of this may be due to the necessary
bookkeeping structures in the C library (malloc), but do you think
this might explain such a huge (4x) overhead?

If I remove the exception handler, I get the SIGSEGV:

Program received signal SIGSEGV, Segmentation fault.
0x40228ee3 in malloc () from /lib/libc.so.6

Back to the original question, is this normal, or should libgnat turn
the SIGSEGV into Storage_Error?

-- 
Ludovic Brenta.