reasons for segmentation faults on linux

reasons for segmentation faults on linux

[Tony]

I'm getting a segmentation fault in linux,

I 've wapped up the storage size and this has no effect, 

I'm using three AVL trees in a task if thats any help

Does anyone know the common reasons for segmentation faults in
Gnat on Linux ?


************************************************************
Everybody is given the same amount of hormones, at birth, and
if you want to use yours for growing hair, that's fine with me.

Re: reasons for segmentation faults on linux

[Marc A. Criley]

Tony wrote:
> 
> I'm getting a segmentation fault in linux,
> 
> I 've wapped up the storage size and this has no effect,
> 
> I'm using three AVL trees in a task if thats any help
> 
> Does anyone know the common reasons for segmentation faults in
> Gnat on Linux ?

Misaligned data...  Dereferencing dangling pointers...  Stack overflows
(if stack checking is disabled)...

Marc

Re: reasons for segmentation faults on linux

[Preben Randhol]

On Wed, 28 Nov 2001 12:49:54 GMT, Marc A. Criley wrote:
> Tony wrote:
>> 
>> I'm getting a segmentation fault in linux,
>> 
>> I 've wapped up the storage size and this has no effect,
>> 
>> I'm using three AVL trees in a task if thats any help
>> 
>> Does anyone know the common reasons for segmentation faults in
>> Gnat on Linux ?
> 
> Misaligned data...  Dereferencing dangling pointers...  Stack overflows
> (if stack checking is disabled)...

Infinite recursion:

procedure A is
begin
   A;
end A;

% gnatmake a.adb 
gnatgcc -c a.adb
a.adb:3:04: warning: possible infinite aursion
a.adb:3:04: warning: Storage_Error may be raised at run time
gnatbind -x a.ali
gnatlink a.ali

% ./a
Segmentation fault

Why isn't Storage_Error raised? GNAT 3.13p on GNU/Debian Linux.

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: reasons for segmentation faults on linux

[Mark Johnson]

Preben Randhol wrote:

> [snip]

> Infinite recursion:
>
> procedure A is
> begin
>    A;
> end A;
>
> % gnatmake a.adb
> gnatgcc -c a.adb
> a.adb:3:04: warning: possible infinite aursion
> a.adb:3:04: warning: Storage_Error may be raised at run time
> gnatbind -x a.ali
> gnatlink a.ali
>
> % ./a
> Segmentation fault
>
> Why isn't Storage_Error raised? GNAT 3.13p on GNU/Debian Linux.
>

RTFM :-). Add -fstack-check to the gnatmake command line to get stack
checking turned on.

As a suggestion, define an environment name w/ the "desired" command line
options & use it instead. At our site...
  GNAT_TESTING="-g -gnata -funwind-tables -gnatO -j3 -gnatn -O2 -gnatwa
-gnatf -fstack-check -gnato -gnatq -gnatU"
and it properly issues the error...

raised STORAGE_ERROR : stack overflow detected

Though perhaps I should submit a bug report to ACT about the warning being in
error if stack checking is suppressed.
  --Mark

Re: reasons for segmentation faults on linux

[David Starner]

On Wed, 28 Nov 2001 15:59:45 +0000 (UTC), Preben Randhol <randhol+abuse@pvv.org> wrote:
> procedure A is
> begin
>    A;
> end A;
> 
> % gnatmake a.adb 
> gnatgcc -c a.adb
> a.adb:3:04: warning: possible infinite aursion
> a.adb:3:04: warning: Storage_Error may be raised at run time
> gnatbind -x a.ali
> gnatlink a.ali
> 
> % ./a
> Segmentation fault
> 
> Why isn't Storage_Error raised? GNAT 3.13p on GNU/Debian Linux.

If I remember the GNAT RM/UG right, trapping stack overflow is
infeasable on Linux system, so by default it doesn't attempt it. There
are switchs you can add to make an attempt at it.

-- 
David Starner - starner@okstate.edu
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis

Re: reasons for segmentation faults on linux

[Robert Dewar]

Preben Randhol <randhol+abuse@pvv.org> wrote in message news:<slrna0a2ch.3dp.randhol+abuse@kiuk0156.chembio.ntnu.no>...
> % gnatmake a.adb 
> gnatgcc -c a.adb
> a.adb:3:04: warning: possible infinite aursion
> a.adb:3:04: warning: Storage_Error may be raised at run time
> gnatbind -x a.ali
> gnatlink a.ali
> 
> % ./a
> Segmentation fault
> 
> Why isn't Storage_Error raised? GNAT 3.13p on GNU/Debian 
> Linux.


Because you chose to run with stack checking disabled,
and GNAT followed your directions!

Re: reasons for segmentation faults on linux

[Robert Dewar]

David Starner <dvdeug@x8b4e53cd.dhcp.okstate.edu> wrote in message news:<9u3okd$9ic2@news.cis.okstate.edu>...


> If I remember the GNAT RM/UG right, trapping stack 
> overflow is
> infeasable on Linux system, so by default it doesn't
> attempt it. There
> are switchs you can add to make an attempt at it.

This is misleading. Stack checking is off in gcc by default
(and gnat always follows general gcc decisions on defaults
for gcc switches, since it would get very confusing if the
defaults were language dependent. If you turn on the switch, you get
stack checking, nothing "infeasible"
about it.

Re: reasons for segmentation faults on linux

[Preben Randhol]

On 28 Nov 2001 19:36:56 -0800, Robert Dewar wrote:
> Because you chose to run with stack checking disabled,
> and GNAT followed your directions!

% set GNAT_STACK_LIMIT=1600

% gnatmake -fstack-check A
gnatgcc -c -fstack-check A.adb
A.adb:3:04: warning: possible infinite Aursion
A.adb:3:04: warning: Storage_Error may be raised at run time
gnatbind -x A.ali
gnatlink A.ali

% ./A 
Segmentation fault

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: reasons for segmentation faults on linux

[Preben Randhol]

On Thu, 29 Nov 2001 10:36:27 +0000 (UTC), Preben Randhol wrote:
> On 28 Nov 2001 19:36:56 -0800, Robert Dewar wrote:
>> Because you chose to run with stack checking disabled,
>> and GNAT followed your directions!
> 
> % set GNAT_STACK_LIMIT=1600
> 
> % gnatmake -fstack-check A
> gnatgcc -c -fstack-check A.adb
> A.adb:3:04: warning: possible infinite Aursion
> A.adb:3:04: warning: Storage_Error may be raised at run time
> gnatbind -x A.ali
> gnatlink A.ali
> 
> % ./A 
> Segmentation fault

ARG! *Bonking my head on the keyboard* 

Forget the above I made the mistake of writing :

   set GNAT_STACK_LIMIT=1600

but in bash shell it is :

   export GNAT_STACK_LIMIT=1600

when I now recompile and run I get.

% ./A

raised STORAGE_ERROR : stack overflow detected

Preben
-- 
 ()   Join the worldwide campaign to protect fundamental human rights.
'||}
{||'                                           http://www.amnesty.org/

Re: reasons for segmentation faults on linux

[David Starner]

On 28 Nov 2001 19:39:01 -0800, Robert Dewar <dewar@gnat.com> wrote:
> This is misleading. Stack checking is off in gcc by default
> (and gnat always follows general gcc decisions on defaults
> for gcc switches, since it would get very confusing if the
> defaults were language dependent. If you turn on the switch, you get
> stack checking, nothing "infeasible"
> about it.

GCC didn't check array accesses by default when GNAT was created. (It
now can do so for Fortran, but doesn't by default, and does for Java.)
Why does GNAT check for array accesses? Stack checking seems more of a
language thing than a general gcc decision.

Why is there GNAT_STACK_LIMIT? If it were feasible to do it cleanly,
then why doesn't GNAT do it that way instead of requiring an additional
enivromental variable?

-- 
David Starner - starner@okstate.edu
Pointless website: http://dvdeug.dhis.org
"I saw a daemon stare into my face, and an angel touch my breast; each 
one softly calls my name . . . the daemon scares me less."
- "Disciple", Stuart Davis