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-Thread: 103376,ae395e5c11de7bc9 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!fdn.fr!gegeweb.org!aioe.org!not-for-mail From: "John B. Matthews" Newsgroups: comp.lang.ada Subject: Re: segfault with large-ish array with GNAT Date: Thu, 18 Mar 2010 10:44:21 -0400 Organization: The Wasteland Message-ID: References: <642ddf8b-1d45-4f74-83ad-2c755040ca33@k24g2000pro.googlegroups.com> <4ba13454$0$6720$9b4e6d93@newsspool2.arcor-online.net> NNTP-Posting-Host: LQJtZWzu+iKlBROuDg+IUg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org X-Notice: Filtered by postfilter v. 0.8.2 User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Xref: g2news2.google.com comp.lang.ada:10621 Date: 2010-03-18T10:44:21-04:00 List-Id: In article , Jerry wrote: > Thanks for the helpful comments. > > First, > ulimit -s unlimited > does not work on OS X: > -bash: ulimit: stack size: cannot modify limit: Operation not > permitted but I understand that it works on Linux. And possibly the > reason is the difference in the way that Linux and OS X treat stack > and heap memory. (Don't be confused and think I know what I'm talking > about but I read that somewhere.) > > ulimit allows querying the hard limit of stack space > ulimit -Hs > which on OS X reports 65532 = 2^16 -4 kilobytes, about 67 MB. The user > via ulimit can set the stack up to that size but not higher: > ulimit -s 65532 > The default soft limit on OS X is 8192 kB, found by > ulimit -s > > So here's me being naive: I would have thought that Ada (or GNAT > specifically) would be smart enough to allocate memory for large > objects such as my long array in a transparent way so that I don't > have to worry about it, thus (in the Ada spirit) making it harder to > screw up. (Like not having to worry about whether arguments to > subprograms are passed by value or by reference--it just happens.) > > But it seems that I will have to allocate memory for large objects > using pointers (and thus take the memory from the heap). Is that > right? I think so. When I ran into this some years ago, I was pleasantly surprised at how easy it was to change over to heap allocation for my largest data structure. Under Mac OS 9, such allocations fragmented the heap, but Mac OS X behaves more reasonably. The menace listed below allocates megabyte-sized blocks right up to the limit of wired memory, as shown by top: ----- with Ada.Text_IO; procedure Heap_Test is Megabyte : constant Positive := 1024 * 1024; type Block is array (0 .. Megabyte - 1) of Character; type Block_Ptr is access all Block; BPtr : Block_Ptr; N : Natural := 1; begin Ada.Text_IO.Put_Line("*** Heap test..."); while True loop BPtr := new Block; Ada.Text_IO.Put (N'Img); N := N + 1; end loop; Ada.Text_IO.New_Line; end Heap_Test; ----- This horror raises STORAGE_ERROR at the `ulimit -s` you showed, but only when compiled with -fstack-check: ----- with Ada.Text_IO; procedure Stack_Test is Megabyte : constant Positive := 1024 * 1024; type Block is array (0 .. Megabyte - 1) of Character; procedure Allocate_Stack (N : Positive) is Local : Block := (others => Character'Val(0)); begin Ada.Text_IO.Put (N'Img); Allocate_Stack(N + 1); end; begin Ada.Text_IO.Put_Line("*** Stack test..."); Allocate_Stack(1); Ada.Text_IO.New_Line; end Stack_Test; ----- For reference, ulimit is a bash built-in, so `man bash` for details: -- John B. Matthews trashgod at gmail dot com