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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,dc258f772c852a1b X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 07 Oct 2005 07:59:36 -0500 Date: Fri, 07 Oct 2005 09:00:10 -0400 From: Jeff Creem User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GNAT GPL for Mac OSX stack checking problem References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.74.171 X-Trace: sv3-4CMTCDJRA0W28XLpMx8Jqpduc1/KnCSCU200WEyuDmFZqlELMz6bXDYQcn8M7/Vwk9lu9Z7oOv0/wma!GegLs+KHiyPvKcy7efLsDvli4t9guz6iZIcwytKqEnd/bfFX0DXqb6KzCFp1IWhseWa9eWzLnA== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news1.google.com comp.lang.ada:5494 Date: 2005-10-07T09:00:10-04:00 List-Id: Kevin K wrote: > The compiler and GPS seem to work, it is the generated test driver > that I'm having problems with. > > I saw 10.3 referenced when I downloaded it, but I have a history with > the Linux versions where you can, at times, run the compiler on a > different version than they built on. For instance, the versions > build for Redhat 7.1 could run on 7.2, 7.3, 8, EL 2.1, but GLIBC > differences essentially required a new version from Adacore for RH9, > EL3, etc. (The change to the new threading library). > > I just took a look at the ulimit command. I would have to look at the > documentation to increase it under macos, but traditionally, the stack > you are changing with this command is the Environment stack, which is > the stack for the actual main procedure, NOT the tasks for individual > tasks. If GNAT, on the Mac, is putting all the tasks I declared in > the procedure declare section into the environment stack, that is > different behavior than any other Ada compiler I've used, since the > Linux GNAT uses the heap, Rational Apex uses the heap, the VADs Ada83 > compiler used the heap, and Alsys on Unix used the heap. > > Essentially, my test procedure was > > procedure test_tasks is > > task type task_type is > pragma storage_size(10000000); > > entry start; > end; > > task body test_tasks is > > begin > > accept start; > > loop > putline("task num"); > delay 10.0; > stack_user; > end loop; > end; > > procedure stack_user is > buffer:string(1..2048); > > begin > buffer(1):=' '; > stack_user; > exception > when storage_error=> text_io.put_line("Storage_Error"); > end; > > the_tasks : array(1..10) of task_type; > > begin > > --Call Start on all tasks > > end; > > It is not clear that one should expect to see 100 Megs actually used on all OS's if the stack check logic is flawed. Some OSs do not actually commit usage of the memory until it is accessed. Given the way this is written, it seems like it would be perfectly valid for the first task to take off and run into that infinite recusion and blow its stack before any other task gets any CPU time. Now if they each did this before the program terminated I guess one would see the 100 Meg usage.. So it sounds like the problem is not really that you are running into an early stack limit but rather that the stack checking is not operating properly resulting in the program terminating instead of each tasking running one after another. Sounds to me like the interaction of gcc and macos is not doing proper stack checking.