segfault with large-ish array with GNAT
in [ADA]
|
From: Robert A Duff on 18 Mar 2010 19:57 Ludovic Brenta <ludovic(a)ludovic-brenta.org> writes: > Jerry wrote on comp.lang.ada: >> I would have thought that Ada (or GNAT >> specifically) would be smart enough to allocate memory for large >> objects such as my long array in a transparent way so that I don't >> have to worry about it, thus (in the Ada spirit) making it harder to >> screw up. (Like not having to worry about whether arguments to >> subprograms are passed by value or by reference--it just happens.) > > So, you would like the Ada run-time to bypass the operating system- > enforced, administrator-approved stack limit? If userspace programs > could do that, what would be the point of having a stack limit in the > first place? Well, yeah, but what IS the point of having a stack limit in the first place? As opposed to a limit on virtual memory use, whether it be stack or heap or whatever. It's useful to limit a process to a certain amount of virtual address space. It prevents that process from hogging the whole system. And it prevents infinite-recursion bugs from causing thrashing. And it prevents infinite-"new" bugs from causing the same. It seems to me, a process should be allowed to allocate its memory however it likes. If it is allowed to allocate (say) 2 gigabytes of address space, then it should be allowed to allocate (say) half of that to the main thread's stack, if it likes. - Bob
From: Jerry on 18 Mar 2010 20:44 On Mar 18, 3:23 am, Ludovic Brenta <ludo...(a)ludovic-brenta.org> wrote: > Jeffrey Creem wrote on comp.lang.ada: <snip> > > If you want the memory to come from the heap, you need to declare the > > variables inside of packages instead of inside procedures. You can then > > avoid using access types. <snip> > > package do_stuff is > > procedure no_bomb; > > end do_stuff; > > > package body do_stuff is > > type Float_Array_Type is array (Integer range <>) of Long_Float; > > -- 1_048_343 causes segmentation fault, 1_048_342 does not. > > x : Float_Array_Type(1 .. 1_048_343); > > > procedure No_bomb is > > > begin > > x(1) := 1.0; > > end No_bomb; > > end do_stuff; > > > with do_stuff; > > procedure stuff is > > > begin > > do_stuff.No_Bomb; > > end stuff; > > No, the array is not in the heap in this case; it is in the executable > program's data segment. This may increase the size of the binary file. > > To ensure that the array is on the heap, it is necessary to use an > access type and an allocator, e.g.: > > type Float_Array_Access_Type is access Float_Array_Type; > x : Float_Array_Access_Type := new Float_Array_Type (1 .. 1_048_343); > > -- > Ludovic Brenta. This (using a package) works. I made two Long_Float arrays of 100_000_000 length. The binary size is 292 KB (I included Text_IO) regardless of the size of the arrays. I'm not sure if I like the programming style better than using access variables. I would have to essentially embed my entire program in a package. And it seems to become impossible to selectively release memory as is possible with access types. But it does solve my problem. I programmed Pascal on Mac OS < 10 for years using pointers to arrays. IIRC the stack was 32 KB. Jerry
From: Jeffrey R. Carter on 19 Mar 2010 00:44 John B. Matthews wrote: > while True loop > ... > end loop; In Ada, we write infinite loops as loop ... end loop; -- Jeff Carter "Now go away or I shall taunt you a second time." Monty Python & the Holy Grail 07
From: John B. Matthews on 19 Mar 2010 04:14 In article <hnuvra$5nk$1(a)tornado.tornevall.net>, "Jeffrey R. Carter" <spam.jrcarter.not(a)spam.acm.org> wrote: > John B. Matthews wrote: > > while True loop > > ... > > end loop; > > In Ada, we write infinite loops as > > loop > ... > end loop; I suppose this is worse! ;-) loop ... exit when False; end loop; -- John B. Matthews trashgod at gmail dot com <http://sites.google.com/site/drjohnbmatthews>
From: Ludovic Brenta on 19 Mar 2010 04:31
Warren wrote on comp.lang.ada: > Imagine > a CPU that somehow in microcode was able to do a fast-malloc > of a stack frame (as part of a call), linking the new > frame back to the calling frame. Then you could eliminate > the need for a "linear virtual stack region" altogether. This > would allow code to freely fork into many parallel > threads without the issue of pre-allocating stack [address] > space to each new thread. When the called procedure executed > a "return", it would (in microcode) free the current stack > frame and return to the prior one. The "call" allocate/free's > could be constrained to one general "stack heap". I wonder how that would work with processors that have register windows specifically to reduce the need for a memory-based stack (i.e. SPARC, IA64 and maybe others). -- Ludovic Brenta. |