* Re: Segmentation Fault [not found] <335358C5.43F8@reading.ac.uk> @ 1997-04-15 0:00 ` Robert Dewar 1997-04-18 0:00 ` Keith Thompson 1997-04-16 0:00 ` William Paul Berriss [not found] ` <33538A67.709A@reading.ac.uk> 2 siblings, 1 reply; 12+ messages in thread From: Robert Dewar @ 1997-04-15 0:00 UTC (permalink / raw) <<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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Segmentation Fault 1997-04-15 0:00 ` Segmentation Fault Robert Dewar @ 1997-04-18 0:00 ` Keith Thompson 1997-04-20 0:00 ` Robert Dewar 0 siblings, 1 reply; 12+ messages in thread From: Keith Thompson @ 1997-04-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Segmentation Fault 1997-04-18 0:00 ` Keith Thompson @ 1997-04-20 0:00 ` Robert Dewar 0 siblings, 0 replies; 12+ messages in thread From: Robert Dewar @ 1997-04-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Segmentation Fault [not found] <335358C5.43F8@reading.ac.uk> 1997-04-15 0:00 ` Segmentation Fault Robert Dewar @ 1997-04-16 0:00 ` William Paul Berriss 1997-04-16 0:00 ` Stack and Heap sizes William Paul Berriss [not found] ` <33538A67.709A@reading.ac.uk> 2 siblings, 1 reply; 12+ messages in thread From: William Paul Berriss @ 1997-04-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stack and Heap sizes 1997-04-16 0:00 ` William Paul Berriss @ 1997-04-16 0:00 ` William Paul Berriss 1997-04-16 0:00 ` Samuel Tardieu 1997-04-18 0:00 ` Robert Dewar 0 siblings, 2 replies; 12+ messages in thread From: William Paul Berriss @ 1997-04-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stack and Heap sizes 1997-04-16 0:00 ` Stack and Heap sizes William Paul Berriss @ 1997-04-16 0:00 ` Samuel Tardieu 1997-04-16 0:00 ` Samuel Tardieu 1997-04-18 0:00 ` Robert Dewar 1 sibling, 1 reply; 12+ messages in thread From: Samuel Tardieu @ 1997-04-16 0:00 UTC (permalink / raw) To: William Paul Berriss >>>>> "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stack and Heap sizes 1997-04-16 0:00 ` Samuel Tardieu @ 1997-04-16 0:00 ` Samuel Tardieu 0 siblings, 0 replies; 12+ messages in thread From: Samuel Tardieu @ 1997-04-16 0:00 UTC (permalink / raw) >>>>> "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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Stack and Heap sizes 1997-04-16 0:00 ` Stack and Heap sizes William Paul Berriss 1997-04-16 0:00 ` Samuel Tardieu @ 1997-04-18 0:00 ` Robert Dewar 1997-04-20 0:00 ` Ada program's use of Stack and Heap William Paul Berriss 1 sibling, 1 reply; 12+ messages in thread From: Robert Dewar @ 1997-04-18 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Ada program's use of Stack and Heap 1997-04-18 0:00 ` Robert Dewar @ 1997-04-20 0:00 ` William Paul Berriss 0 siblings, 0 replies; 12+ messages in thread From: William Paul Berriss @ 1997-04-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <33538A67.709A@reading.ac.uk>]
* Re: Segmentation Fault [not found] ` <33538A67.709A@reading.ac.uk> @ 1997-04-15 0:00 ` Charlie Root 1997-04-16 0:00 ` Nicolas HUYNH 1 sibling, 0 replies; 12+ messages in thread From: Charlie Root @ 1997-04-15 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Segmentation Fault [not found] ` <33538A67.709A@reading.ac.uk> 1997-04-15 0:00 ` Segmentation Fault Charlie Root @ 1997-04-16 0:00 ` Nicolas HUYNH [not found] ` <3355DB39.3BAF@reading.ac.uk> 1 sibling, 1 reply; 12+ messages in thread From: Nicolas HUYNH @ 1997-04-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <3355DB39.3BAF@reading.ac.uk>]
* Re: I've Sussed my Segmentation Fault [not found] ` <3355DB39.3BAF@reading.ac.uk> @ 1997-04-19 0:00 ` Robert Dewar 0 siblings, 0 replies; 12+ messages in thread From: Robert Dewar @ 1997-04-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1997-04-20 0:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <335358C5.43F8@reading.ac.uk> 1997-04-15 0:00 ` Segmentation Fault Robert Dewar 1997-04-18 0:00 ` Keith Thompson 1997-04-20 0:00 ` Robert Dewar 1997-04-16 0:00 ` William Paul Berriss 1997-04-16 0:00 ` Stack and Heap sizes William Paul Berriss 1997-04-16 0:00 ` Samuel Tardieu 1997-04-16 0:00 ` Samuel Tardieu 1997-04-18 0:00 ` Robert Dewar 1997-04-20 0:00 ` Ada program's use of Stack and Heap William Paul Berriss [not found] ` <33538A67.709A@reading.ac.uk> 1997-04-15 0:00 ` Segmentation Fault Charlie Root 1997-04-16 0:00 ` Nicolas HUYNH [not found] ` <3355DB39.3BAF@reading.ac.uk> 1997-04-19 0:00 ` I've Sussed my " Robert Dewar
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox