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