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,7bdbcdc23dd9313d,start
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news2.google.com!postnews.google.com!v17g2000prc.googlegroups.com!not-for-mail
From: Jerry <lanceboyle@qwest.net>
Newsgroups: comp.lang.ada
Subject: Large arrays passed to arithmetic operators overflows GNAT stack
Date: Fri, 3 Dec 2010 22:32:59 -0800 (PST)
Organization: http://groups.google.com
Message-ID: 
 <da4fcb09-efa7-46d4-aece-e86b0dcf6674@v17g2000prc.googlegroups.com>
NNTP-Posting-Host: 75.172.183.76
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1291444380 18747 127.0.0.1 (4 Dec 2010 06:33:00
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Sat, 4 Dec 2010 06:33:00 +0000 (UTC)
Complaints-To: groups-abuse@google.com
Injection-Info: v17g2000prc.googlegroups.com; posting-host=75.172.183.76;
 posting-account=x5rpZwoAAABMN2XPwcebPWPkebpwQNJG
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-US)
 AppleWebKit/531.21.8+(KHTML, like Gecko, Safari/528.16) (null),gzip(gfe)
Xref: g2news2.google.com comp.lang.ada:16766
Date: 2010-12-03T22:32:59-08:00
List-Id: <comp.lang.ada>

For what it's worth, passing large numerical arrays to the arithmetic
operators in GNAT can cause the stack to overflow (segfault) even when
the arrays are allocated from the heap. I suppose that indicates that
they are being copied rather than being passed by reference.

For example, on OS X which has a default stack size of 8192 KB, the
following program segfaults when N is greater than about 1_048_138
(about 8 MB per Long_Float array) but runs OK when it is somewhat less
than that number.

with
    Ada.Numerics.Long_Real_Arrays;
use
    Ada.Numerics.Long_Real_Arrays;
procedure array_test is
    type Real_Vector_Access    is access Real_Vector;
    N : Integer :=3D 1_048_130;
    t_Ptr : Real_Vector_Access :=3D new Real_Vector(0 .. N);
      t : Real_Vector renames t_Ptr.all;
    t_Diff_Ptr : Real_Vector_Access :=3D new Real_Vector(0 .. N - 1);
      t_Diff : Real_Vector renames t_Diff_Ptr.all;
begin
    for i in t'range loop
        t(i) :=3D 1.0;
    end loop;
    t_Diff :=3D t(1 .. N) - t(0 .. N - 1);
end array_test;

The quick fix (in my case) is to increase the stack size from the
shell:

ulimit -s 65532

or whatever is appropriate for your machine--65532 is the hard limit
set by OS X.

Another way to expand the stack without invoking shell commands, as
noted by Bj=F6rn Persson on this thread

http://groups.google.com/group/comp.lang.ada/browse_thread/thread/ae395e5c1=
1de7bc9/bda8d61bd3a66ee9?hl=3Den&q=3DJerry+stack&lnk=3Dnl&

is to call getrlimit and/or setrlimit from within the program, linking
to these POSIX C routines.

Another fix would be to write operator procedures that specifically
take pointers as arguments; that would possibly be the only fix for
arrays that still overflow the stack when it is maxed out.

As usual, taking the dumb-guy approach, this seems like an unnecessary
nuisance.

Jerry