GNAT Ada runtime Exception = message EXCEPTION_STACK_OVERFLOW

Question

I'am trying to run my application after compiling it with AdaCores GPS (Gnat Programming Studio).

I get the run time error

Exception name: STORAGE_ERROR
Message: EXCEPTION_STACK_OVERFLOW

I get these run time errors despite setting the stack size in the binder options using

-d65535 (task stack size) and -D65535 (secondary stack size) (I also have tried 65535k on both as well as 655m).

The application runs well when compiling it with the Aonix Object Ada compiler. In the Aonix compiler I set the - stack size to 65535, - the secondary stack size to 65535 - and the Task stack size to 46345.

My main aim is to port the application to the GNAT Ada compiler.

I notice -d sets the task stack size and -D the secondary stack size but I can't see where to set the main stack size, and I am assuming that this is the issue with the application, but please correct me if I am looking in the wrong direction.

Any pointers would be greatly appreciated appreciated.

Bearslumber

Answer 1

If the problem is indeed the main task, a workaround is to move the main procedure to the body of a helper task.

Answer 2

First, compile for debug (-g) (there may be other relevant options; posting wrong information is the fastest way to find them ;-) and you should get more information : the source line and file that raised the exception. Or a stack trace which you can analyze via addr2line.

That should help understand why it is raising...

• Are you allocating hundreds of MB on the stack? I've got away with about 200MB in the past...
• Is the raise within one of the container classes or part of the RTS?
• Is the message actually misleading and a new() heap allocation failed? Other things than the stack can raise Storage_Error, and I'm not clear how or if the default handler distinguishes the cause...

We can't proceed further down this path without further information : edit it into the question and I'll take another look.

Setting stack size for the environment task is not directly possible within Gnat. It's part of gcc's interaction with the OS, and supposed to use the system's ulimit settings for the resulting executable (on Linux; other OS may vary)...

Unfortunately, around the gcc/gnat 4.5 timeframe I found evidence these were being ignored, though that may have been corrected, and I haven't revisited that problem.

I have seen Alex's answer posted elsewhere as a viable workround if the debug trace and ulimit settings don't provide the answer, or if you need to press on instead of spending time debugging. To keep the codebase clean, I would suggest a wrapper, simply creating the necessary task and calling your current main procedure. For Aonix you simply don't need to include the wrapper file in your build.