Howto debug seg-faulting Ada 95 code?

Howto debug seg-faulting Ada 95 code?

[Karl Ran]

Hello,

I've written this nice, but not very useful, Ada 95 program:

------------------------------------------------------------
with Ada; use Ada;
with Ada.Text_IO;

procedure segfault_city is

   type Unsigned_8  is mod 2**8;
   for Unsigned_8'Size  use  8;
   type Data  is array( 0 .. 100 ) of Unsigned_8;
   type block is array( 0 .. 200 ) of Data;

   Buffers : array( 0 .. 310 ) of block;

   task type fifo_Task
   is
   end fifo_Task;

   My_fifo : fifo_Task;

   task body fifo_Task
   is
   begin
      Text_IO.Put_line("fifo_task ..");
   end fifo_Task;

begin
   Buffers( 0 )( 0 )( 0 ) := 0;
   Text_IO.Put_line("Welcome to segfault city ..");
end Segfault_city;
------------------------------------------------------------

It compiles fine with gnat 3.14p( options: -gnatwa -gnato -g )
but it fails miserably when I run it.

It either seg-faults immediately or it eats up all memory and 
gets killed. I tried it on P1, Celeron, P4 systems with
Linux 2.4.18/Suse7.1/8.0.

Some questions:
1. How do I debug seg-faults( this case and in general )?
2. Is this valid Ada 95 code?
3. Is this segfault-code 'portable' or are these just my, maybe, ill
   configured systems?

Karl,
who is still using 'bleeding-edge' technology...

Re: Howto debug seg-faulting Ada 95 code?

[Florian Weimer]

karlran@hotmail.com (Karl Ran) writes:

[Program which exceeds the 2 MB stack barrier when tasking is used on
GNAT/x86]

> It compiles fine with gnat 3.14p( options: -gnatwa -gnato -g )
> but it fails miserably when I run it.

Your code causes a stack overflow; "-fstack-check" should catch these
problems, but it doesn't.  Looks like a bug to me.

Re: Howto debug seg-faulting Ada 95 code?

[Karl Ran]

Florian Weimer <fw@deneb.enyo.de> wrote in message 
> Your code causes a stack overflow; "-fstack-check" should catch these
> problems, but it doesn't.  Looks like a bug to me.

Is there a work-around for this software defect, other than using 'new'?

Where can I find a list of known software defects of gnat 3.14p?

Thanks,
Karl

Re: Howto debug seg-faulting Ada 95 code?

[Jeffrey Creem]

Well. It may be a bug that it is not caught properly but if it were, all you
would be left with is a Storage_Error exception in the place of the
segfault.

You are blowing the stack because you are trying to declare a large
structure on within a procedure (be it the main procedure or a sub
program)..

Either use new or declare the variable at the library level (in a package)
to make it
go on the heap.

"Karl Ran" <karlran@hotmail.com> wrote in message
news:1f358d66.0209020705.6769d948@posting.google.com...
> Florian Weimer <fw@deneb.enyo.de> wrote in message
> > Your code causes a stack overflow; "-fstack-check" should catch these
> > problems, but it doesn't.  Looks like a bug to me.
>
> Is there a work-around for this software defect, other than using 'new'?
>
> Where can I find a list of known software defects of gnat 3.14p?
>
> Thanks,
> Karl

Re: Howto debug seg-faulting Ada 95 code?

[Pat Rogers]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:FhMc9.91102$kp.733909@rwcrnsc52.ops.asp.att.net...
<snip>
> You are blowing the stack because you are trying to declare a large
> structure on within a procedure (be it the main procedure or a sub
> program)..
>
> Either use new or declare the variable at the library level (in a
package)
> to make it go on the heap.

What has a declaration at the library level have to do with the heap?

Re: Howto debug seg-faulting Ada 95 code?

[Florian Weimer]

karlran@hotmail.com (Karl Ran) writes:

> Florian Weimer <fw@deneb.enyo.de> wrote in message 
>> Your code causes a stack overflow; "-fstack-check" should catch these
>> problems, but it doesn't.  Looks like a bug to me.
>
> Is there a work-around for this software defect, other than using
> 'new'?

Which defect?  The stack overflow?  Well, you'd have to use an
architecture which offers 64 bit pointers.  ("new" does not raise
Storage_Errore reliably either because physical memory is usually
allocated not as soon a logical memory region is allocated, but only
if the memory region is written to.)

I don't know any workarounds for the bug in "-fstack-check" which your
code triggers.

> Where can I find a list of known software defects of gnat 3.14p?

No such list is publicly available, I guess.

Re: Howto debug seg-faulting Ada 95 code?

[Jeffrey Creem]

> "Jeffrey Creem" <jeff@thecreems.com> wrote in message
> news:FhMc9.91102$kp.733909@rwcrnsc52.ops.asp.att.net...
> <snip>
> > Either use new or declare the variable at the library level (in a
> package)
> > to make it go on the heap.
>
> What has a declaration at the library level have to do with the heap?
>
>

Techically nothing..I don't believe I have ever read anything in the LRM
that
says for sure that if you declare a variable in a package it goes on the
heap but
if you declare it in a procedure (including the mainline) it goes on the
stack. (See, now
why did Robert have to go and leave...Where is Tucker Taft when you need
him)

Having said that, every compiler I have used does something like this.  It
also tends to
make intuitive sense.

Re: Howto debug seg-faulting Ada 95 code?

[Pat Rogers]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:RNRc9.336566$UU1.57839@sccrnsc03...
>
> > "Jeffrey Creem" <jeff@thecreems.com> wrote in message
> > news:FhMc9.91102$kp.733909@rwcrnsc52.ops.asp.att.net...
> > <snip>
> > > Either use new or declare the variable at the library level (in
a
> > package)
> > > to make it go on the heap.
> >
> > What has a declaration at the library level have to do with the
heap?
> >
> >
>
> Techically nothing..I don't believe I have ever read anything in the
LRM
> that
> says for sure that if you declare a variable in a package it goes on
the
> heap but
> if you declare it in a procedure (including the mainline) it goes on
the
> stack. (See, now
> why did Robert have to go and leave...Where is Tucker Taft when you
need
> him)
>
> Having said that, every compiler I have used does something like
this.  It
> also tends to
> make intuitive sense.

Humm, every compiler I have used did not.  Declarations within library
units are just the first things pushed. We don't think of that initial
stack push as being a stack operation because it is never "popped"
until the program completes.

Re: Howto debug seg-faulting Ada 95 code?

[David C. Hoos, Sr.]

This code runs perfectly well on my RedHat 7.2
GNAT 3.14 system under my normal shell environment
which is tcsh with the following resource limits
(obtained by issuing the "limit" command):

cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8192 kbytes
coredumpsize    unlimited
memoryuse       unlimited
descriptors     1024 
memorylocked    unlimited
maxproc         1023 
openfiles       1024 

I can make it segfault if I set the stacksize
limit to 6171 kbytes.  With 6172 kbytes it runs OK.

So, there is no "software defect" as has been
suggested, but merely a case of failure to provide
an execution environment in which the program is to
execute, having adequate resources to accommodate
the program's design.

One could change the design to allocate on the
heap, which would merely shift the resource
requirement from stacksize to datasize.

If you are using the bash shell, the command for
adjusting per-process resource limits is "ulimit".



----- Original Message ----- 
From: "Karl Ran" <karlran@hotmail.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: August 31, 2002 2:58 AM
Subject: Howto debug seg-faulting Ada 95 code?


> Hello,
> 
> I've written this nice, but not very useful, Ada 95 program:
> 
> ------------------------------------------------------------
> with Ada; use Ada;
> with Ada.Text_IO;
> 
> procedure segfault_city is
> 
>    type Unsigned_8  is mod 2**8;
>    for Unsigned_8'Size  use  8;
>    type Data  is array( 0 .. 100 ) of Unsigned_8;
>    type block is array( 0 .. 200 ) of Data;
> 
>    Buffers : array( 0 .. 310 ) of block;
> 
>    task type fifo_Task
>    is
>    end fifo_Task;
> 
>    My_fifo : fifo_Task;
> 
>    task body fifo_Task
>    is
>    begin
>       Text_IO.Put_line("fifo_task ..");
>    end fifo_Task;
> 
> begin
>    Buffers( 0 )( 0 )( 0 ) := 0;
>    Text_IO.Put_line("Welcome to segfault city ..");
> end Segfault_city;
> ------------------------------------------------------------
> 
> It compiles fine with gnat 3.14p( options: -gnatwa -gnato -g )
> but it fails miserably when I run it.
> 
> It either seg-faults immediately or it eats up all memory and 
> gets killed. I tried it on P1, Celeron, P4 systems with
> Linux 2.4.18/Suse7.1/8.0.
> 
> Some questions:
> 1. How do I debug seg-faults( this case and in general )?
> 2. Is this valid Ada 95 code?
> 3. Is this segfault-code 'portable' or are these just my, maybe, ill
>    configured systems?
> 
> Karl,
> who is still using 'bleeding-edge' technology...
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
> 
> 

Re: Howto debug seg-faulting Ada 95 code?

[Sergey Koshcheyev]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:FhMc9.91102$kp.733909@rwcrnsc52.ops.asp.att.net...
> Either use new or declare the variable at the library level (in a package)
> to make it
> go on the heap.


I would say that x86 compilers place library-level data in data sections,
initialized or unininitialized. This is the best place for them, and data
sections aren't stack nor heap, they're something else :-) I don't know
about other architectures, but I suspect the placement of global data is
similar there.

Sergey.

Re: Howto debug seg-faulting Ada 95 code?

[Karl Ran]

Florian Weimer <fw@deneb.enyo.de> wrote in message 

> > Is there a work-around for this software defect, other than using
> > 'new'?
> 
> Which defect?  The stack overflow?  Well, you'd have to use an
> architecture which offers 64 bit pointers.  ("new" does not raise
> Storage_Errore reliably either because physical memory is usually
> allocated not as soon a logical memory region is allocated, but only
> if the memory region is written to.)

Thanks for your explanation.

You mentioned a 2 MB stack barrier in 87y9an5tt2.fsf@deneb.enyo.de.
Would you please give me a hint where this limit comes from?
Is it related to GNAT_STACK_LIMIT?

Thanks,
Karl

Re: Howto debug seg-faulting Ada 95 code?

[Karl Ran]

"David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message > This code runs perfectly well on my RedHat 7.2
> GNAT 3.14 system under my normal shell environment

Thanks for your report.

> I can make it segfault if I set the stacksize
> limit to 6171 kbytes.  With 6172 kbytes it runs OK.

Would you please recompile my test code with '-fstack-check'?

> So, there is no "software defect" as has been
> suggested, but merely a case of failure to provide
> an execution environment in which the program is to
> execute, having adequate resources to accommodate
> the program's design.

Well, in Forian`s and in my case the compiled code fails to raise
STORAGE_ERROR when compiled with '-fstack-check'!

The result is a segmentation fault - but it can be worse, right? 
 

Another point is that neither Florina nor myself is using a
ACT-certified
Linux distribution :-/

Karl

Re: Howto debug seg-faulting Ada 95 code?

[Jeffrey Creem]

"Pat Rogers" <progers@classwide.com> wrote in message
news:asSc9.5091$Ss7.1261527110@newssvr30.news.prodigy.com...
> >
> > Having said that, every compiler I have used does something like
> this.  It
> > also tends to
> > make intuitive sense.
>
> Humm, every compiler I have used did not.  Declarations within library
> units are just the first things pushed. We don't think of that initial
> stack push as being a stack operation because it is never "popped"
> until the program completes.
>
>

Well, as I said there is nothing in the LRM that I know of that requires
either behaviour so
it is certainly possible that you are correct.

Another poster was more precise when he said he sees x86 compilers put these
in the
data segment (initialized or uninitiazed).

The compiler I have seen which put package level variables "not on the
stack" are

VADS -> 68K vxWorks
VADS -> MIPS vxWorks
VADS -> PowerPC vxWorks
Apex -> Solaris
GNAT -> Solaris
GNAT -> win32/linux

It seems like a strange convention to allocate package level variables on
the stack. It now means
that in a multi-tasking program you have tasks mucking in the stack of
another task.... Again, no reason
that I can think of that this would not work but it does feel odd.

Re: Howto debug seg-faulting Ada 95 code?

[Samuel Tardieu]

>>>>> "Sergey" == Sergey Koshcheyev <serko84@hotmail.com> writes:

Sergey> I would say that x86 compilers place library-level data in
Sergey> data sections, initialized or unininitialized. This is the
Sergey> best place for them, and data sections aren't stack nor heap,
Sergey> they're something else :-) I don't know about other
Sergey> architectures, but I suspect the placement of global data is
Sergey> similar there.

Yup, exactly. In general, you have the following memory areas when you
execute a program: (the first three usually come from the executable
file if this has any sense in your environment)

  + text:   contains executable code
  + data:   contains pre-initialized data
  + bss:    same as data, but content is initialized to zero (convenient
            to avoid storing those zeroes in the executable file)
  + heap:   where your global allocations come from
  + stacks: not shared between thread of controls (each one may have
            several stacks) - those stacks may be allocated in the heap
            or may be separate

 Sam
-- 
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/sam

Re: Howto debug seg-faulting Ada 95 code?

[David C. Hoos, Sr.]

Compiling with -fstack-check results in exactly the same
behavior, unless the environment variable
GNAT_STACK_LIMIT is set -- in which case STORAGE_ERROR
is raised with the message "stack overflow detected"
if the GNAT_STACK_LIMIT is set below 6170.

It would be a good thing to read carefully the
GNAT User's Guide section on stack checking --
particularly with regard to the environment task -- since
it is in the environment task that you are experiencing
stack overflow.

With regard to "ACT-certified" Linux distributions,
RedHat 7.2 isn't "certified" either -- only 6.2, if I
recall.  The only problem I encountered with GNAT on
RedHat 7.2 was related to support for symbolic call-stack
tracing, and I fixed those problems myself.

The last time I looked at SuSe was in early 1999 when I
evaluated Slackware, SuSe and RedHat.  I decided against
SuSe for reasons unrelated to GNAT -- my preference for
System V over BSD, and the fact that the SuSe English
documentation was clearly translated (from German?) by
persons for whom English is not their native tongue.
I preferred the better (though imperfect) English of the
RedHat distribution for the sake of my customer.

----- Original Message -----
From: "Karl Ran" <karlran@hotmail.com>
Newsgroups: comp.lang.ada
To: <comp.lang.ada@ada.eu.org>
Sent: September 03, 2002 4:38 AM
Subject: Re: Howto debug seg-faulting Ada 95 code?


> "David C. Hoos, Sr." <david.c.hoos.sr@ada95.com> wrote in message > This code runs perfectly well
on my RedHat 7.2
> > GNAT 3.14 system under my normal shell environment
>
> Thanks for your report.
>
> > I can make it segfault if I set the stacksize
> > limit to 6171 kbytes.  With 6172 kbytes it runs OK.
>
> Would you please recompile my test code with '-fstack-check'?
>
> > So, there is no "software defect" as has been
> > suggested, but merely a case of failure to provide
> > an execution environment in which the program is to
> > execute, having adequate resources to accommodate
> > the program's design.
>
> Well, in Forian`s and in my case the compiled code fails to raise
> STORAGE_ERROR when compiled with '-fstack-check'!
>
> The result is a segmentation fault - but it can be worse, right?
>
>
> Another point is that neither Florina nor myself is using a
> ACT-certified
> Linux distribution :-/
>
> Karl
> _______________________________________________
> comp.lang.ada mailing list
> comp.lang.ada@ada.eu.org
> http://ada.eu.org/mailman/listinfo/comp.lang.ada
>
>

Re: Howto debug seg-faulting Ada 95 code?

[Pat Rogers]

"Jeffrey Creem" <jeff@thecreems.com> wrote in message
news:_V0d9.120646$_91.183808@rwcrnsc51.ops.asp.att.net...
>
> "Pat Rogers" <progers@classwide.com> wrote in message
> news:asSc9.5091$Ss7.1261527110@newssvr30.news.prodigy.com...
> The compiler I have seen which put package level variables "not on
the
> stack" are
>
> VADS -> 68K vxWorks
> VADS -> MIPS vxWorks
> VADS -> PowerPC vxWorks
> Apex -> Solaris
> GNAT -> Solaris
> GNAT -> win32/linux

Humm (to continue that phrase:), sounds like I need to check some
things.

RE: Howto debug seg-faulting Ada 95 code?

[Steven Deller]

To be precise:
  text : is ANY read-only item, both code and data constants
  data : is read-write items with an initial value (on systems that
permit code to modify itself, any code that is modified goes here with
data)
  bss  : is read-write without an initial value (it is NOT required to
be initialized to zero, but is on many systems).
  ...

> -----Original Message-----
> From: comp.lang.ada-admin@ada.eu.org 
> [mailto:comp.lang.ada-admin@ada.eu.org] On Behalf Of Samuel Tardieu
> Sent: Tuesday, September 03, 2002 6:43 AM
> To: comp.lang.ada@ada.eu.org
> Subject: Re: Howto debug seg-faulting Ada 95 code?
> 
...
> Yup, exactly. In general, you have the following memory areas 
> when you execute a program: (the first three usually come 
> from the executable file if this has any sense in your environment)
> 
>   + text:   contains executable code
>   + data:   contains pre-initialized data
>   + bss:    same as data, but content is initialized to zero 
> (convenient
>             to avoid storing those zeroes in the executable file)
>   + heap:   where your global allocations come from
>   + stacks: not shared between thread of controls (each one may have
>             several stacks) - those stacks may be allocated 
> in the heap
>             or may be separate
> 
>  Sam

>