* GNAT GPL for Mac OSX stack checking problem @ 2005-10-06 22:47 Kevin K 2005-10-07 1:27 ` jim hopper 2005-10-07 2:48 ` John B. Matthews 0 siblings, 2 replies; 9+ messages in thread From: Kevin K @ 2005-10-06 22:47 UTC (permalink / raw) I've downloaded the new 2005 GPL edition for the Mac (of which I am NOT an expert, having the computer for only 2 weeks). I wrote a test program using tasks, namely a program with 10 tasks, of 10Meg each. However, even when compiled with the -fstack-check option, not only is the virtual memory usage not anywhere close to the the 100meg expected, but when run, when I attempt to get a storage_error, I get an illegal instruction instead. This same test procedure compiled on the Linux version of Gnat 2005, running Centos4, runs as expected. I guess the question is what is the maximum stack size of a task under OSX? (10.4 with all available patches) Is there a missing option I need to do when compiling or linking under OSX? I know that Windows has some special options. The test driver is available for posting. Thanks, Kevin -- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-06 22:47 GNAT GPL for Mac OSX stack checking problem Kevin K @ 2005-10-07 1:27 ` jim hopper 2005-10-07 12:10 ` Kevin K 2005-10-07 2:48 ` John B. Matthews 1 sibling, 1 reply; 9+ messages in thread From: jim hopper @ 2005-10-07 1:27 UTC (permalink / raw) Kevin you should check out macada.org and join the mac ada mailing lisst for mac specific questions. there is a gnat there that is built from apples version of the source, and additions so you can use osx's xcode ide etc. best jim In article <KIRoJuEXw9g9-pn2-JDKN54ZBmMfZ@ecs>, Kevin K <kevink4@gmail.com> wrote: > I've downloaded the new 2005 GPL edition for the Mac (of which I am > NOT an expert, having the computer for only 2 weeks). > > I wrote a test program using tasks, namely a program with 10 tasks, of > 10Meg each. > > However, even when compiled with the -fstack-check option, not only is > the virtual memory usage not anywhere close to the the 100meg > expected, but when run, when I attempt to get a storage_error, I get > an illegal instruction instead. > > This same test procedure compiled on the Linux version of Gnat 2005, > running Centos4, runs as expected. > > I guess the question is what is the maximum stack size of a task under > OSX? (10.4 with all available patches) > > Is there a missing option I need to do when compiling or linking under > OSX? I know that Windows has some special options. > > The test driver is available for posting. > > Thanks, > Kevin ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-07 1:27 ` jim hopper @ 2005-10-07 12:10 ` Kevin K 0 siblings, 0 replies; 9+ messages in thread From: Kevin K @ 2005-10-07 12:10 UTC (permalink / raw) I'll check out that mailing list. For some reason, I must not have entered in the right options on google looking for help, since I don't recall seeing it listed. On Fri, 7 Oct 2005 01:27:29 UTC, jim hopper <hopperj@macconnect.com> wrote: > Kevin > > you should check out macada.org and join the mac ada mailing lisst for > mac specific questions. there is a gnat there that is built from > apples version of the source, and additions so you can use osx's xcode > ide etc. > > best jim > > > In article <KIRoJuEXw9g9-pn2-JDKN54ZBmMfZ@ecs>, Kevin K > <kevink4@gmail.com> wrote: > > > I've downloaded the new 2005 GPL edition for the Mac (of which I am > > NOT an expert, having the computer for only 2 weeks). > > > > I wrote a test program using tasks, namely a program with 10 tasks, of > > 10Meg each. > > > > However, even when compiled with the -fstack-check option, not only is > > the virtual memory usage not anywhere close to the the 100meg > > expected, but when run, when I attempt to get a storage_error, I get > > an illegal instruction instead. > > > > This same test procedure compiled on the Linux version of Gnat 2005, > > running Centos4, runs as expected. > > > > I guess the question is what is the maximum stack size of a task under > > OSX? (10.4 with all available patches) > > > > Is there a missing option I need to do when compiling or linking under > > OSX? I know that Windows has some special options. > > > > The test driver is available for posting. > > > > Thanks, > > Kevin -- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-06 22:47 GNAT GPL for Mac OSX stack checking problem Kevin K 2005-10-07 1:27 ` jim hopper @ 2005-10-07 2:48 ` John B. Matthews 2005-10-07 12:25 ` Kevin K ` (2 more replies) 1 sibling, 3 replies; 9+ messages in thread From: John B. Matthews @ 2005-10-07 2:48 UTC (permalink / raw) In article <KIRoJuEXw9g9-pn2-JDKN54ZBmMfZ@ecs>, "Kevin K" <kevink4@gmail.com> wrote: > I've downloaded the new 2005 GPL edition for the Mac > [...] > I guess the question is what is the maximum stack size of a task under > OSX? (10.4 with all available patches) > [...] You can examine & modify the stack limit using the bash shell's built-in ulimit command: $ ulimit -s 8192 Looks like eight megabytes. I see that GNAT GPL 2005 Edition specifies Mac OS X Server 10.3. Does it work under 10.4? Non-server? -- John jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-07 2:48 ` John B. Matthews @ 2005-10-07 12:25 ` Kevin K 2005-10-07 13:00 ` Jeff Creem 2005-10-08 6:27 ` Simon Wright 2005-10-08 18:01 ` jim hopper 2 siblings, 1 reply; 9+ messages in thread From: Kevin K @ 2005-10-07 12:25 UTC (permalink / raw) 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; The above test driver would not have run on older Linux releases using LinuxThreads since the glibc limited task stack sizes to 2Meg. So, in those versions of Linux, we used the FSU threads which could be larger. I just wanted to see if MacOS had a similar limitation. On Fri, 7 Oct 2005 02:48:22 UTC, "John B. Matthews" <nospam@nospam.com> wrote: > In article <KIRoJuEXw9g9-pn2-JDKN54ZBmMfZ@ecs>, > "Kevin K" <kevink4@gmail.com> wrote: > > > I've downloaded the new 2005 GPL edition for the Mac > > [...] > > I guess the question is what is the maximum stack size of a task under > > OSX? (10.4 with all available patches) > > [...] > > You can examine & modify the stack limit using the bash shell's built-in > ulimit command: > > $ ulimit -s > 8192 > > Looks like eight megabytes. > > I see that GNAT GPL 2005 Edition specifies Mac OS X Server 10.3. Does it > work under 10.4? Non-server? > -- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-07 12:25 ` Kevin K @ 2005-10-07 13:00 ` Jeff Creem 2005-10-08 0:05 ` Kevin K 0 siblings, 1 reply; 9+ messages in thread From: Jeff Creem @ 2005-10-07 13:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-07 13:00 ` Jeff Creem @ 2005-10-08 0:05 ` Kevin K 0 siblings, 0 replies; 9+ messages in thread From: Kevin K @ 2005-10-08 0:05 UTC (permalink / raw) On Fri, 7 Oct 2005 13:00:10 UTC, Jeff Creem <jcreem@yahoo.com> 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-07 2:48 ` John B. Matthews 2005-10-07 12:25 ` Kevin K @ 2005-10-08 6:27 ` Simon Wright 2005-10-08 18:01 ` jim hopper 2 siblings, 0 replies; 9+ messages in thread From: Simon Wright @ 2005-10-08 6:27 UTC (permalink / raw) "John B. Matthews" <nospam@nospam.com> writes: > I see that GNAT GPL 2005 Edition specifies Mac OS X Server > 10.3. Does it work under 10.4? Non-server? Its identification triplet is powerpc-apple-darwin7.4.1, and it's built on GCC 3.4.5. It runs fine (on a limited test!) on 7.9.0. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GNAT GPL for Mac OSX stack checking problem 2005-10-07 2:48 ` John B. Matthews 2005-10-07 12:25 ` Kevin K 2005-10-08 6:27 ` Simon Wright @ 2005-10-08 18:01 ` jim hopper 2 siblings, 0 replies; 9+ messages in thread From: jim hopper @ 2005-10-08 18:01 UTC (permalink / raw) if you do (on os X) limit stacksize unlimited then ulimit -s gives 65536 so that would appear to be all you can get. jim In article <nospam-36089F.22481206102005@news-rdr-02.ohiordc.rr.com>, John B. Matthews <nospam@nospam.com> wrote: > $ ulimit -s > 8192 > > Looks like eight megabytes. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2005-10-08 18:01 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-10-06 22:47 GNAT GPL for Mac OSX stack checking problem Kevin K 2005-10-07 1:27 ` jim hopper 2005-10-07 12:10 ` Kevin K 2005-10-07 2:48 ` John B. Matthews 2005-10-07 12:25 ` Kevin K 2005-10-07 13:00 ` Jeff Creem 2005-10-08 0:05 ` Kevin K 2005-10-08 6:27 ` Simon Wright 2005-10-08 18:01 ` jim hopper
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox