Re: GNAT GPL for Mac OSX stack checking problem

["Kevin K" <kevink4@gmail.com>]

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.