Task stack overflow problem with GNAT

Task stack overflow problem with GNAT

[fabien_bousquet]

Hi,
I have a task which is raising a Storage_Error exception ("Stack
overflow").
I am using the compiler GNAT 3.13p.
I have tried to put in the specification of my task type a "pragma
Storage_Size(32000)" and it has changed nothing !!
Is there another way to change a task stack size with the GNAT or have
I misunderstood the usage of the pragma Storage_Size ?

Thanks in advance,
Fabien Bousquet


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Task stack overflow problem with GNAT

[Marc A. Criley]

fabien_bousquet@my-deja.com wrote:
> 
> Hi,
> I have a task which is raising a Storage_Error exception ("Stack
> overflow").
> I am using the compiler GNAT 3.13p.
> I have tried to put in the specification of my task type a "pragma
> Storage_Size(32000)" and it has changed nothing !!
> Is there another way to change a task stack size with the GNAT or have
> I misunderstood the usage of the pragma Storage_Size ?
> 
One thing that that needs to be done to help narrow down the problem is to
determine exactly where the raising of the Storage_Error is occurring.  Is there
something obvious there, like trying to declare a huge object that would be
placed in the stack space?

Or is there nothing suspicious at the point where the Storage_Error is raised? 
I experienced this frequently on a previous program on which I worked, and there
were two solutions:

1) Find big data items and dynamically allocate them off the heap, rather than
having them reside on the stack.

2) Increase the task storage size, as you said you've done.  You state that you
raised it to 32K and there's still a problem.  Actually, that's not surprising
to me.  We usually started at 32K and went up.  The largest Storage_Size
allocation we had to use is on the order of 160K.  We didn't do this across the
board, but would just bump it up whenever it occurred (after scrubbing for any
instances of unwarranted large objects or looking for instances where option #1
might be useful).

Marc

Re: Task stack overflow problem with GNAT

[fabien_bousquet]

In article <39DE061B.51F62B69@icdc.com>,
  "Marc A. Criley" <mcriley@icdc.com> wrote:
> fabien_bousquet@my-deja.com wrote:
> >
> > Hi,
> > I have a task which is raising a Storage_Error exception ("Stack
> > overflow").
> > I am using the compiler GNAT 3.13p.
> > I have tried to put in the specification of my task type a "pragma
> > Storage_Size(32000)" and it has changed nothing !!
> > Is there another way to change a task stack size with the GNAT or
have
> > I misunderstood the usage of the pragma Storage_Size ?
> >
> One thing that that needs to be done to help narrow down the problem
is to
> determine exactly where the raising of the Storage_Error is
occurring.  Is there
> something obvious there, like trying to declare a huge object that
would be
> placed in the stack space?
>
> Or is there nothing suspicious at the point where the Storage_Error
is raised?
> I experienced this frequently on a previous program on which I
worked, and there
> were two solutions:
>
> 1) Find big data items and dynamically allocate them off the heap,
rather than
> having them reside on the stack.
>
> 2) Increase the task storage size, as you said you've done.  You
state that you
> raised it to 32K and there's still a problem.  Actually, that's not
surprising
> to me.  We usually started at 32K and went up.  The largest
Storage_Size
> allocation we had to use is on the order of 160K.  We didn't do this
across the
> board, but would just bump it up whenever it occurred (after
scrubbing for any
> instances of unwarranted large objects or looking for instances where
option #1
> might be useful).
>
> Marc
>
My code is supposed to be embedded and I do not use dynamic allocation.
My code is object oriented and it contains a lot of operators.
The stack overflow is sent on a overriding operator "-" during the
fourth execution of a task.
I am not sure but I suppose that this could be linked to the usage of
protected object in the synchronisation between tasks.
I will try the pragma Storage_Size(160000).

Thanks,
Fabien Bousquet


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Task stack overflow problem with GNAT

[Ted Dennison]

fabien_bousquet@my-deja.com wrote:

> My code is supposed to be embedded and I do not use dynamic allocation.

Do you mean you don't have a heap and access to the "new" operator at all,
or do you mean you do, but you aren't supposed to use them?

There should be no problem in performing dynamic allocation in an embedded
system, as long as you do it once at startup rather than repetedly at
runtime.

--
T.E.D.

Home - mailto:dennison@telepath.com  Work - mailto:dennison@ssd.fsi.com
WWW  - http://www.telepath.com/dennison/Ted/TED.html  ICQ  - 10545591

Re: Task stack overflow problem with GNAT

[fabien_bousquet]

> Do you mean you don't have a heap and access to the "new" operator at
all,
> or do you mean you do, but you aren't supposed to use them?
I do not use the operator new. You are right I could use it before the
real time phase, but for the moment I have tried to use aliased
variable and only static allocation. I do not have very big datas to
manipulate, except my inputs which are declared as static variables in
the main package.

Thanks,
Fabien


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Task stack overflow problem with GNAT

[Pat Rogers]

"Ted Dennison" <dennison@telepath.com> wrote in message
news:3A094BF4.C737809F@telepath.com...
> fabien_bousquet@my-deja.com wrote:
>
> > My code is supposed to be embedded and I do not use dynamic
allocation.
>
> Do you mean you don't have a heap and access to the "new" operator
at all,
> or do you mean you do, but you aren't supposed to use them?
>
> There should be no problem in performing dynamic allocation in an
embedded
> system, as long as you do it once at startup rather than repetedly
at
> runtime.

Well, yes, if you don't have control over the allocator behavior.  On
the other hand, deterministic behavior is the issue, and given a
deterministic allocator you can do dynamic allocation in the real-time
part as well (other issues not being prohibitive).  That's a good
reason to build your own pools, which is why I include one in my
real-time course.

PS: It is all "dynamic".

---
Patrick Rogers                      Consulting and Training in:
http://www.classwide.com      Deadline Schedulability Analysis
progers@classwide.com        Software Fault Tolerance
(281)648-3165                       Real-Time/OO Languages

Adam ... does not deserve all the credit; much is due to Eve, the
first woman, and Satan, the first consultant.
Mark Twain

Re: Task stack overflow problem with GNAT

[Steven Deller]

In article <UZkE5.1266$m75.233863@nnrp1.sbc.net>,
  "Pat Rogers" <progers@NOclasswideSPAM.com> wrote:
> "Ted Dennison" <dennison@telepath.com> wrote in message
> news:3A094BF4.C737809F@telepath.com...
> > fabien_bousquet@my-deja.com wrote:
> >
> > > My code is supposed to be embedded and I do not use dynamic
> allocation.

Fabien,
You say the overflow occurs when using a redefined "-" operator.  This
problem smells suspiciously like an unintended recursion.  I have seen
this before, where the definition of an operator either directly or
indirectly ends up calling itself, with the result that no matter how
long the stack is, you are going to run out of stack at that point.

I'd suggest using a post-failure debugger to see what calls are on the
stack (I know how to do that with Rational Apex -- not sure with GNAT).
That should quickly tell you if there are lots of stacked calls to the
"-" operator.  If so, then you have your culprit.

Regards,
Steve Deller
deller@rational.com (recently retired :-) :-) )


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: Task stack overflow problem with GNAT

[fabien_bousquet]

Steve,
Your remark is good but my operator is called many times before the
crash, and the stack information I have with gdb is just two functions
which are not mine (the last one is _image_base).
Definitively, it looks like a GNAT bug !!

Thanks,
Fabien


Sent via Deja.com http://www.deja.com/
Before you buy.