Re: exception access violation

Georg Bauhaus wrote:

Why is using the heap + controlled for larger data structures
more portable than using the stack? I know that GNAT needs to
be talked into providing sufficient space on the stack.
You might be that running into this kind of stack trouble only
when you port from another compiler to GNAT?

I have no experiences out of GNAT, that be said first.

In past times, I had to deal with implicit limits in Linux/ld (I seem to
remember it was 2MB. This has changed with kernels and is no longer an
issue). Because of this, porting from Windows to Linux was somewhat painful
because problems not arising in Windows did arise in Linux (even using the
usual linker stack options, so I had to dig for even more obscure
switches). Other languages don't exploit so much the stack, so it is more
difficult to find experiences in the area from other developers.

Other point that may be relevant: by default, gnat doesn't release memory
historically claimed by stacks, contrarily to heap-allocated one. Couple
this with lots of tasks or recursivity and quickly memory can start to be
an issue. (I'm not sure if this is linux 2.6 default behavior or gnat
management of secondary stacks, couldn't locate it in the docs).

Finally is the trap I always fall for: "This is small enough to be in the
stack". And then it grows, and then it starts to be a problem, or some
recursive algorithm can't recurse enough, and you end changing it or having
humongous stacks or reworking algorithms.

Of course, in realtime environments you'll prefer to know your memory needs
from the start.

Should the decision whether some object lives on the heap or on
the stack be based on compilers' support for dynamically sized
local data structures?

As long as compilers are not perfect, I suppose it is at least an extra
factor to consider. Also, I'd not limit it only to dynamically sized data.

I've been bitten several times by stack-related problems when using GNAT,
that's all I wanted to transmit (hence the 'in my experience' remark). If
you don't have desires to learn about system internals, GNAT
primary/secondary stacks and so... use the heap, luke ;)

It is worrysome that I'm saying all this, because I find much more
comfortable using the stack than any heap management.
.

Relevant Pages

  • GNAT and -fstack-check, does it work?
    ... In a recent or current c.l.a thread on "ada compiler" the OP was advised to use the gnatmake options -gnato and -fstack-check to make GNAT a full Ada compiler, with run-time checks for arithmetic overflow and stack overflow, respectively. ...
    (comp.lang.ada)
  • Re: ada compiler?
    ... is a GNAT compiler option while '-lfstack-check; ... Ada written stack checking code. ... While the GCC version uses GCC ...
    (comp.lang.ada)
  • Re: GNAT Spitbol segmentation fault
    ... If you have used Gnat Spitbol before, could you comment if I'm doing ... Compile with -fstack-check and/or try increasing the stack space of the ... conversion to String within the Spitbol code that's overflowing the stack. ...
    (comp.lang.ada)
  • Re: Gnat storage size
    ... types is limited to under 4 megabytes of data with Gnat 3.15p on Windows? ... "For declared tasks, the stack size is controlled by the size given in an ... For the environment task, the stack size depends on system defaults and is ...
    (comp.lang.ada)
  • Re: stack overflow
    ... >> What are some different approaches to dealing with stack overflows ... See if you really need the recursivity. ... IIRC a search in a BST ...
    (comp.lang.cpp)