gnatbind get stack overflow, how do I investigate the cause?

Petter Fryklund

unread,

Mar 30, 2017, 9:00:34 AM3/30/17

to

Hi all,

after a couple of years with C# I'm back! I am currently porting a large project from Ada-95 in ObjectAda to GNAT 17, first on Linux and later on W7. I've managed to compile the all files, but gnatbind hits a stack overflow. How do I get more information about the cause?

Regards,
Petter

Anh Vo

unread,

Mar 30, 2017, 9:51:29 AM3/30/17

to

On Thursday, March 30, 2017 at 6:00:34 AM UTC-7, Petter Fryklund wrote:
> Hi all,
>
> after a couple of years with C# I'm back! I am currently porting a large project from Ada-95 in ObjectAda to GNAT 17, first on Linux and later on W7. I've managed to compile the all files, but gnatbind hits a stack overflow. How do I get more information about the cause?

I have never had this kind of problem with GNAT. Since you are using GNAT 17, you must have support contract. I would create a ticket with AdaCore. In the mean time, could you post the exact gnatbind error message.

Anh Vo

Dmitry A. Kazakov

unread,

Mar 30, 2017, 10:30:25 AM3/30/17

to

Are you sure? Usually it is the compiler that runs out of memory. It
happens very often if you have many generic instances.

The only solution I know is splitting compilation units. Important is
the "distance". If you move X into packet Q that is "with"-ed in the
packet P where compiler ran out of memory that is the distance 1. This
is not enough. The distance must be at least 2. Therefore separate
bodies do not help. Packing generic instances into a collection package
does not help. etc.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Per Sandberg

unread,

Mar 30, 2017, 12:22:09 PM3/30/17

to

Hi

I did the same journey a on our system many years ago, and it was
"interesting" since we found a whole bunch of serious bugs just by
follow up on warnings and later enable all validity checks.

You might increase the stacksize with:
-dnn[k|m] Default primary stack size = nn [kilo|mega] bytes
-Dnn[k|m] Default secondary stack size = nn [kilo|mega] bytes
from "gnatbind -h"

And expect a bunch of elaboration circles that needs to be broken out by
factoring out generics and separates into child packages.

And as Anh mentions ask AdaCore, since they usually gives good answers.

/Per

Petter Fryklund

unread,

Mar 31, 2017, 1:11:00 AM3/31/17

to

Hi again,
Isn't -d for the produced output? it is the gnatbind itself that suffers from Storage_Error hinting at stack overflow.

The output from gnatbind is:
[gprbind] <main>.bexch
[Ada] <main>.ali

raised STORAGE_ERROR : stack overflow or erroneous memory access
gprbind: invocation of gnatbind failed
gprbuild: unable to bind <main>.adb

Anh Vo: yes we have support, I or the person responsible for tools will create a ticket ASAP. In the meanwhile I'd like to gather information.

Regards,
Petter

Anh Vo

unread,

Mar 31, 2017, 2:13:13 PM3/31/17

to

On Thursday, March 30, 2017 at 10:11:00 PM UTC-7, Petter Fryklund wrote:
> Hi again,
> Isn't -d for the produced output? it is the gnatbind itself that suffers from Storage_Error hinting at stack overflow.
>
> The output from gnatbind is:
> [gprbind] <main>.bexch
> [Ada] <main>.ali
>
> raised STORAGE_ERROR : stack overflow or erroneous memory access
> gprbind: invocation of gnatbind failed
> gprbuild: unable to bind <main>.adb

Did the problem occur under Linux or W7 or both? I assume that your are porting host to host, not host to cross target, right?

Anh Vo

Petter Fryklund

unread,

Apr 3, 2017, 1:26:15 AM4/3/17

to

Hi again,

the error occurred on Linux. I've yet to try on W7. We are porting host to host and also some cross to host, since ObjectAda where used as cross to VxWorks as well. I now have a ticket at AdaCore: [Q331-004] #1935.

Regards,
Petter