ERC-32 RTEMS Stack Overflow?

[Joel Sherrill]

steved94 wrote:
> 
> Silly question, but have you tried something along the lines of:
> 
>  TASK TYPE Solution_Process IS
>     PRAGMA Storage_Size( 524_288 );
>     ENTRY Start;
>   END Solution_Process;
> 
> This is not a GNAT/RTEMS answer, but rather a straight Ada answer (I haven't
> tried it).

That works for all but the main task which is a bit special since it
is explicitly created.  The RTEMS hello world Ada example shows how to
change the attribute set of the initial main Ada task including 
the stack size.

And generically, allocating large data structures on the stack in an
embedded system is not a good idea.  You have to be very careful about
how much stack is allocated per task.

Jiri needs to comment on any hw stack checking support.

> SteveD
> 
> ----- Original Message -----
> From: "Alan Brain" <abrain at auspace.com.au>
> To: <rtems-users at oarcorp.com>
> Sent: Wednesday, November 14, 2001 2:30 PM
> Subject: RE: ERC-32 RTEMS Stack Overflow?
> 
> > 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?
> >

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985