From: Niklas Holsti <niklas.holsti@tidorum.invalid>
Subject: GNAT and -fstack-check, does it work?
Date: Sun, 11 Nov 2007 23:09:07 +0200
Date: 2007-11-11T23:09:07+02:00 [thread overview]
Message-ID: <47375ee3$0$27835$39db0f71@news.song.fi> (raw)
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. I'm not sure if
-fstack-check is enough, or is working as expected.
I have been using those options for a while, but I was recently hit
by a bug in which stack overflow made the program abort with
Segmentation Violation (signal 11 = SIGSEGV) instead of the
expected Storage_Error exception. This is under Debian Sarge with
gnat 3.15p. In fact the Ada program simply stopped with no error
messages, and I had to run it under the Linux "strace" tool before
I found out that it was killed by SIGSEGV. (I found out later that
GDB also shows the SIGSEGV, at least from a post-mortem core dump.)
While investigating this problem I learned some things:
- According to the GNAT User Guide (at least the version
at gcc.gnu.org) the option -fstack-check does not always
work for the stack of the environment task, that is, for
the "main" stack, because GNAT may not know the actual
size allocated (or allocatable) for this stack. You must
also set the environment variable GNAT_STACK_LIMIT to
the size of the stack (in kilobytes) when the compiled
Ada program is started.
- The behaviour on my system depends on whether the Ada
program is linked dynamically (using shared libraries) or
statically. With dynamic libraries the environment task
stack limit is set by the shell command "ulimit -s". My
default ulimit is 8 MB which was enough to avoid stack
overflow in this case. With static libraries the stack
limit on my system seems to be around 2 MB even if a
larger "ulimit" is used or a larger value is set with
the "-d" option for gnatbind. This smaller size led to
stack overflow and SIGSEGV in my program. I have seen
some web references that explain that the 2 MB limit
occurs because some versions of libpthread.a have
hard-coded stack size for threads, and my version
seems to have that.
- There is an open GCC bug (bug 13757, "-fstack-check
causes segfaults") that says that "-fstack-check" can
generate buggy code that *sometimes* causes a
segfault, depending on the placement of the stack
relative to page boundaries, thus depending on the
length of the environment variables, the length of
the command name (program path name), and whether the
program is invoked directly or via GDB. Ugh.
I'd appreciate to hear from the c.l.a crowd:
- Does -fstack-check work for you? Which versions of
GNAT, which systems? Do you need to set GNAT_STACK_LIMIT
too?
- Is the behaviour different for dynamic linking and
static linking? Which GNAT, which system?
- Have you had problems like those described in bug 13757?
Do you know if that bug affects GNAT?
Thanks...
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
next reply other threads:[~2007-11-11 21:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-11 21:09 Niklas Holsti [this message]
2007-11-14 9:49 ` GNAT and -fstack-check, does it work? Stefan Bellon
2007-11-14 10:05 ` Georg Bauhaus
2007-11-14 11:31 ` Niklas Holsti
2007-11-14 12:03 ` Stefan Bellon
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox