Re: GNAT GPL for Mac OSX stack checking problem

[Jeff Creem <jcreem@yahoo.com>]

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.