Re: Segmentation Fault

Re: Segmentation Fault

[Charlie Root]

William Paul Berriss (W.P.Berriss@reading.ac.uk) wrote:
   When I change the 64X64X64 to a 128X128X128 they both crash at
   run-time giving Segmentation Fault.

   Thus I cannot ask for a 6 megabyte chunk of memory on
   a Sun.  
   	Is this correct?  Why?

It may be that you do not allocate the memory dynamically
using "new", but implicitly declaring a local variable 
for example. In that case it typically is allocated on the
stack, which should be large enough. 

Use the Storage_Size pragma for the task that allocates
these large chunks of memory, setting the size to 30 MB
for example. On most modern systems having a large stack
doesn't hurt as long as you do not touch it. So the memory
is only actually needed when you *use* the whole stack.

I do think however that Ada compilers should provide
larger stacks by default on platforms as described above.
Bob Duff recently described a good approach for this,
without requiring too much virtual address space.

Regards,
   Geert

Re: Segmentation Fault

[Nicolas HUYNH]

I tried with Ada 83, on a SPARC 10 under SunOS 5.4.

I get a STORAGE_ERROR exception,
which is much more explanatory than Segmentation Fault
for someone who is used to Ada ... isn't it ?

Why does the program generated with GNAT by W.P.Berriss
not generate a STORAGE_ERROR ? Is there a problem with GNAT ?


Nicolas

Re: I've Sussed my Segmentation Fault

[Robert Dewar]

William Berriss asks

<<Anyone know how to set heap sizes in GNAT>>

This has nothing to do with GNAT, by default GNAT just uses malloc, so you
have to find out how memory is handled by the underlying operating system
environment.

Re: Segmentation Fault

[Robert Dewar]

<<This all works fine, compiles, runs etc.
BUT, if I rewrite the program and ask for a 128 X 128 X 128 bin
array, it compiles fine but when I come to run it it says ...>

Sounds like a stack overflow to me, what makes you think it is anything else?

Re: Segmentation Fault

[Keith Thompson]

In <dewar.861113004@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
[...]
> Sounds like a stack overflow to me, what makes you think it is anything else?

Perhaps he expected a stack overflow to raise Storage_Error rather than
causing a segmentation fault.

GNAT disables certain run-time checks by default.  To enable them, use
the "-o" or "-gnato" option.

-- 
Keith Thompson (The_Other_Keith) kst@sd.aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
5040 Shoreham Place, San Diego, CA, USA, 92122-5989
"Humor is such a subjective thing." -- Cartagia

Re: Segmentation Fault

[Robert Dewar]

keith said

<<Perhaps he expected a stack overflow to raise Storage_Error rather than
causing a segmentation fault.

GNAT disables certain run-time checks by default.  To enable them, use
the "-o" or "-gnato" option.>>

Perhaps everyone should read the documentation :-)
The vesion of GNAT he is using clearly says in the documentation that
stack checking is not implemented. Specifying -gnato (not -o ... which
is something else entirely) will not affect this

Re: Segmentation Fault

[William Paul Berriss]

Hi

Here is the Ada code, v simple.

--
-- Filename :    test_memory_allocation.adb
--
-- Programmer :  Will Berriss
--
-- Machine : stssrita (SunOs 5.3,   a.k.a. Solaris 2.3 )
--
-- Compiler : GNAT 3.07 Ada 95 for Solaris 2.3/2.4/2.5
--            (Installed 3 February 1997 by WPB)
--
-- Date :   15 April 1997
--
-- Edited :
--

with Ada.Command_Line, Ada.Sequential_IO, Ada.Text_IO,
Ada.Integer_Text_IO;
use Ada.Text_IO, Ada.Integer_Text_IO;
--with EEG.Image_IO;

with  EEG.Pixel_Types;             -- For a 512X512 Image type Image,
and type Colour_Pixel
use   EEG.Pixel_Types;             -- and types XCoordinate etc of
Steve's

procedure Test_Memory_Allocation is


   RedMax, GreenMax, BlueMax : Natural := 0;

begin

    Put("Enter No of Red Coordinates  :  ");
    Get(RedMax);
    Put("Enter No of Green Coordinates  :  ");
    Get(GreenMax);
    Put("Enter No of Blue Coordinates  :  ");
    Get(BlueMax);

    New_Line;
    Put("Each bin is a Natural, 4 bytes .");
    New_Line;

    Put("Your Array is of Size : ");
    Put(Natural(RedMax * GreenMax * BlueMax * (Natural'Size / 8)));
    Put("  bytes.");
    New_Line;

    A:declare


      subtype RedRange is Natural range 0 .. RedMax -1;
      subtype GreenRange is Natural range 0 .. GreenMax -1;
      subtype BlueRange is Natural range 0 .. BlueMax -1;


    type Hist_Array is array( RedRange, GreenRange, BlueRange ) of
Natural;

    H : Hist_Array := (others => (others => (others => 0)));

    begin  -- A

      H(1,1,1) := 1;

  end A;

end Test_Memory_Allocation;


Enteriung 85, 85, 85 is fine, but entering 128, 128, 128
causes segmentation fault.

Will
-----
-- 

W P Berriss                 E-mail: W.P.Berriss@reading.ac.uk
Department of Engineering
The University of Reading
Whiteknights
Reading                     Tel:  0118 987 5123 
Berkshire                     (+44 118 987 5123 outside UK)
RG6 6AY    
England                     Fax:  0118 931 3327    

World Wide Web Home Page: 

http://www.elec.rdg.ac.uk/people/postgrads/will.html

Re: Stack and Heap sizes

[William Paul Berriss]

Hi

A few quick questions.

Is there a limit that GNAT imposes on the size of the
stack or heap available to the main program or
on an object (such as an array)?

Is there a compiler option to alter the limit?

Is there a way to find out what the limit is
at a given time (say on a 2Gbyte RAM machine?)

Thanks

Will Berriss
------------

-- 

W P Berriss                 E-mail: W.P.Berriss@reading.ac.uk
Department of Engineering
The University of Reading
Whiteknights
Reading                     Tel:  0118 987 5123 
Berkshire                     (+44 118 987 5123 outside UK)
RG6 6AY    
England                     Fax:  0118 931 3327    

World Wide Web Home Page: 

http://www.elec.rdg.ac.uk/people/postgrads/will.html

Re: Stack and Heap sizes

[Samuel Tardieu]

>>>>> "William" == William Paul Berriss <W.P.Berriss@reading.ac.uk> writes:

William> Is there a limit that GNAT imposes on the size of the stack
William> or heap available to the main program or on an object (such
William> as an array)?

No. The stack for the elaboration task (the one which does all the
elaborations and then calls the main program) can grow as long as
there is enough memory (it depends on your hardware and OS). Same for
heap if you use the default storage pool.

It is different for other tasks, where a pragma Storage_Size may be
specified to change the default stack size.

  Sam
--
Samuel Tardieu -- sam@ada.eu.org

Re: Stack and Heap sizes

[Samuel Tardieu]

>>>>> "Sam" == Samuel Tardieu <sam@ada.eu.org> writes:

Sam> No. The stack for the elaboration task (the one which does all
Sam> the elaborations and then calls the main program) can grow as
Sam> long as there is enough memory (it depends on your hardware and
Sam> OS).

Followup on myself: on Unix systems, you can usually change the
stacksize limit with your shell's "limit" builtin command. If your Ada 
program is launched from some other program, then consider using the
setrlimit() system call to increase the maximum stack size.

  Sam
--
Samuel Tardieu -- sam@ada.eu.org

Re: Stack and Heap sizes

[Robert Dewar]

W P Berriss asks

<<A few quick questions.

Is there a limit that GNAT imposes on the size of the
stack or heap available to the main program or
on an object (such as an array)?

Is there a compiler option to alter the limit?

Is there a way to find out what the limit is
at a given time (say on a 2Gbyte RAM machine?)>>

GNAT imposes no limit on the stack or heap available to the main program

There is no compiler option to alter the limit, since this is an
operating system issue. Many operating systems do have mechanisms for
adjusting the stack size (you did not even say what system you were
using).

Again, finding out the limit is an operating system issue. It is unlikely
that the sioze depends on how much RAM you have.

Re: Ada program's use of Stack and Heap

[William Paul Berriss]

Hi

I use Solaris 2.5 on a Sun SPARC 5 , and GNAT Ada95 v3.05.

I have got my programs to work now:  From what I have done,
I deduce the following (which may be only *almost* correct).

When I declare an array that has any runtime determined sizes,
then my program does NOT use the Stack  - I proved this because
if I make stack huge using Solaris 2.5 commands then my program
will work ONLY if I fix all the array sizes at compile time.
e.g. 
 type Hist_Array is array( Pixel, Pixel, Pixel ) of Natural;
 where type Pixel is defined as a Natural range 0..255.

BUT, if I decide on size at runtime then I get Segmentation Fault!
If I use *new* I also get Segmentation Fault, for such a 
64Megabyte array (even when I have limited stacksize to 2 gigabytes!).
(Same goes for my C++ version incidently.)

I can only presume that when I had a runtime size determined
array, my program it was using the Heap? not the Stack, and
hence threw up Segmentation Fault as the Heap was not big enough.
Definitely not the stack anyway.  And I cannot set the Heap
limit (to my knowledge) using Solaris UNIX commands (e.g. limit)


I have a number of programs that now work!

Incidently, one of them did not work at first, it declared
3 of these huge arrays.  
It siad Segemntation Fault again, despite big stack size
and fixed arrya size.
The only difference with this program
was that I had forgotton to use 

(others => (others => (others => 0 )));

when I declare the objects of this array type.

As soon as I made this one change everything worked!!!

When my program was *not* using *others*, 
it was as if the 64MB chunk of stack  I declared was
unusable because it was full of junk (not zeros).
When I came to use file_io.read data into this array it gave me
Segmentation Fault.  

(It was definitely the Read (i.e using
the declared but unitialise array ) that
threw up the error as I commented it out during a test.)

With the comments removed and using others 
the others cured it!
Odd?

Anyway, that was how I got *my* program to work OK, as they now do,
so it may be worth trying if you have the same problem?

Feel free to add to this theory? or improve upon it!

Will Berriss
------------

-- 

W P Berriss                 E-mail: W.P.Berriss@reading.ac.uk
Department of Engineering
The University of Reading
Whiteknights
Reading                     Tel:  0118 987 5123 
Berkshire                     (+44 118 987 5123 outside UK)
RG6 6AY    
England                     Fax:  0118 931 3327    

World Wide Web Home Page: 

http://www.elec.rdg.ac.uk/people/postgrads/will.html