2

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

bearslumber
  • 31
  • 4

2 Answers2

1

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

Álex
  • 1,587
  • 11
  • 17
  • 2
    This is a useful workround if you can’t adjust the main program’s stack size; you _can_ alter an individual task’s stack size right there in the source using aspect `Storage_Size` or the equivalent pragma ([ARM J.15.4](http://www.ada-auth.org/standards/12rm/html/RM-J-15-4.html)). – Simon Wright Aug 25 '15 at 20:48
  • What is the correct way to change the stack size of the main program (environment task) on Windows using the community edition of GNAT? – Marcello90 Sep 13 '19 at 21:42
1

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.

  • Thanks Brian, Alex Simon and NWS. – bearslumber Aug 27 '15 at 11:33
  • Hi Guys. Thanks for your pointers. Firstly I shall try varying the stack sizes and check to see if the exe varies accordingly. I am currently compiling with no optimisations. Next step when I see varying sizes of the exe I shall run it in debug mode. I already have a stack dump but the place where it falls over doesn't seem to make sense. Ill keep the thread posted. – bearslumber Aug 27 '15 at 11:40
  • Hi Guys back. I managed to find the correct linker switch to set the Main Stack size. The switches are passed to the linker (GnatLink) and are -XLinker --stack=0x. This helped me build with the correct stack and was able to step through the program, but I then got a page segmentation fault during a call to a win32 operation. I had been linking with the Aonix port so no wonder i got the fault . I then ensured I linked with the GNAT port, but I also upgraded in the meantime and now I can't get the linker to work at all. GPRBuild just reports that the linker is not launched. Doh! – bearslumber Sep 01 '15 at 11:15