ERC-32 RTEMS Stack Overflow?

Alan Brain abrain at auspace.com.au
Wed Nov 14 22:30:27 UTC 2001


G'day to one and all.

For my sins, I'm leading the spaceflight software development team
on the Australian FedSat microsatellite programme. Although it's
only a 50 kg satellite, it has 5 experiments on board, so has a
fairly complex set of software. CPU is an ERC-32. Compiler is
GNAT 13.11p with RTEMS.

We've been having some problems which appear to be due to a systemic
stack overflow problem. Basically,

package body Foo is
   
   procedure Bar is
      some_local : a_large_data_structure_T; -- will be put on stack?
   begin
      do_stuff;
   end Bar;

end Foo;

will cause problems somewhere in the system, a task will die,
or a memory error will occur, usually in a part of the program
remote from the cause.

If we change to

package body Foo is
   
   used_to_be_some_local : a_large_data_structure_T; -- not on stack?
   
   procedure Bar is     
   begin
      do_stuff;
   end Bar;

end Foo;
 
Then the problem goes away.

It appears that if a_large_data_structure_T'SIZE is >256*8 the
problem occurs, but we have been too busy working around the
problem to investigate it.

Questions to the list:
a) Has this been noted before? If so, where can I find doco on it?
b) Is there a patch (to GNAT or RTEMS) that gets around it?

We strongly suspect that it's a stack corruption problem due to the
use of the ERC-32/Spark's hardware method for detection of stack end,
where if I understand it correctly there's a 256-byte magic marker
inserted at end-of-stack. So allocation of a large data object (>256 bytes)
will completely blow this and cause over-run into memory parts unknown.

Or it could be something else entirely. Comments, please? 



More information about the users mailing list