GNAT GPL for Mac OSX stack checking problem

GNAT GPL for Mac OSX stack checking problem

[Kevin K]

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

-- 

Re: GNAT GPL for Mac OSX stack checking problem

[jim hopper]

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

Re: GNAT GPL for Mac OSX stack checking problem

[Kevin K]

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


-- 

Re: GNAT GPL for Mac OSX stack checking problem

[John B. Matthews]

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/

Re: GNAT GPL for Mac OSX stack checking problem

[Kevin K]

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?
> 


-- 

Re: GNAT GPL for Mac OSX stack checking problem

[Jeff Creem]

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.

Re: GNAT GPL for Mac OSX stack checking problem

[Kevin K]

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.

Re: GNAT GPL for Mac OSX stack checking problem

[Simon Wright]

"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.

Re: GNAT GPL for Mac OSX stack checking problem

[jim hopper]

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.