From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,872c9f672f291e9b X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!feeder.news-service.com!newsfeed.freenet.de!news.tiscali.de!uio.no!fi.sn.net!newsfeed1.fi.sn.net!news.song.fi!not-for-mail Date: Wed, 14 Nov 2007 13:31:58 +0200 From: Niklas Holsti User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20060628 Debian/1.7.8-1sarge7.1 X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GNAT and -fstack-check, does it work? References: <47375ee3$0$27835$39db0f71@news.song.fi> <20071114104918.248861fb@cube.tz.axivion.com> In-Reply-To: <20071114104918.248861fb@cube.tz.axivion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <473acc11$0$27828$39db0f71@news.song.fi> Organization: TDC Song Internet Services NNTP-Posting-Host: laku61.adsl.netsonic.fi X-Trace: 1195035665 news.song.fi 27828 81.17.205.61:32815 X-Complaints-To: abuse@song.fi Xref: g2news1.google.com comp.lang.ada:18366 Date: 2007-11-14T13:31:58+02:00 List-Id: Stefan Bellon wrote: > On Sun, 11 Nov, Niklas Holsti wrote: > > [-gnato -fstack-check] > >>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. > > > We are hit by that bug, feature or whatever it is since GNAT 3.15p > onwards (up to GNAT Pro 6.0.2 now). It seems to be some combination of > options. We just decided not to specify -fstack-check. But perhaps it's > something we are missing. > > BTW: We are on Debian as well (although always unstable). Thanks for this information. Can you also say if this happens with the environment task stack, or some other (declared) task stack? Did you set the GNAT_STACK_LIMIT variable? >>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? > > > I see something like ... > > Execution terminated by unhandled exception > Exception name: STORAGE_ERROR > Message: stack overflow (or erroneous memory access) > Call stack traceback locations: > 0x43d76e99 > > ... whenever I execute an application compiled with our switches: > > -gnat05 -gnata -gnatef -gnatf -gnatn -gnatU -gnatwa -gnatwl > -gnatyaAbdefhiklmnprtx -O0 -g -gnato -fstack-check Do I understand correctly that this happens even when your application does not really cause stack overflow? That is, you get a *spurious* report of stack overflow? In my case, the stack overflow was real (a problem in the size computed for a local array in my application, now fixed) but the reaction to the overflow was not what I expected, and shows that -fstack-check did not detect the overflow, perhaps because I did not set GNAT_STACK_LIMIT. If I set GNAT_STACK_LIMIT to a value smaller than the attempted stack allocation I do get a Storage_Error and a stack-overflow message, showing that in my system -fstack-check depends on GNAT_STACK_LIMIT, at least for the environment task. >>- Have you had problems like those described in bug 13757? >> Do you know if that bug affects GNAT? > > > We have never used -fstack-check with C code, I'm afraid. Well, bug 13757 may be a bug in the GCC back-end and then it could affect also Ada programs. If -fstack-check (in combination with some other options) causes spurious stack-overflow exceptions in your applications, it might be related to this bug. But your spurious exceptions seem to be more reliable (systematic) than the description of bug 13757 suggests, where it speaks of stack-frame alignments depending on the length of the program name and so on. My conclusions so far: I will reconsider the use of -fstack-check and static linking when I upgrade from GNAT 3.15p to the new Debian GNAT. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .