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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsmst01b.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr11.news.prodigy.com.POSTED!660be329!not-for-mail From: "Kevin K" Message-ID: Newsgroups: comp.lang.ada Subject: Re: GNAT GPL for Mac OSX stack checking problem References: User-Agent: ProNews/2 V1.57.cp107 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit NNTP-Posting-Host: 68.92.114.81 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr11.news.prodigy.com 1128729936 ST000 68.92.114.81 (Fri, 07 Oct 2005 20:05:36 EDT) NNTP-Posting-Date: Fri, 07 Oct 2005 20:05:36 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: FKPO@MC@OXTMQS@[GJJB^T\BUSXB@DTMNHWB_EYLJZ]BGIELCNSKQFCY@TXDX_WHSVB]ZEJLSNY\^J[CUVSA_QLFC^RQHUPH[P[NRWCCMLSNPOD_ESALHUK@TDFUZHBLJ\XGKL^NXA\EVHSP[D_C^B_^JCX^W]CHBAX]POG@SSAZQ\LE[DCNMUPG_VSC@VJM Date: Sat, 08 Oct 2005 00:05:36 GMT Xref: g2news1.google.com comp.lang.ada:5504 Date: 2005-10-08T00:05:36+00:00 List-Id: On Fri, 7 Oct 2005 13:00:10 UTC, Jeff Creem wrote: > 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. I'll stick in a small delay statement in the recursive procedure that will slow down the tasks, in case, for some reason, the Macos version of the runtime doesn't timeslice. Regardless, I would have thought that the memory usage according to top would have shown at least 10 meg if only 1 task was running.