* STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW @ 2005-08-05 0:55 Adaddict 2005-08-05 1:21 ` Adaddict ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Adaddict @ 2005-08-05 0:55 UTC (permalink / raw) Greetings, I'm doing a small program that uses a search function. That search function compares a given string with the strings returned by a second function until that second function can't return another string. During the execution of that search I get that error. Does anyone know what causes it and how could I solve it? P.S: Using GNAT 3.15p on AdaGIDE to develop a Win32 app. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW 2005-08-05 0:55 STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW Adaddict @ 2005-08-05 1:21 ` Adaddict 2005-08-06 11:21 ` How to set the stack size on GNAT (Follow-up) Adaddict 2005-08-09 22:05 ` Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large Adaddict 2 siblings, 0 replies; 16+ messages in thread From: Adaddict @ 2005-08-05 1:21 UTC (permalink / raw) Sorry, just after posting this I noticed the other thread about this error. My apologises. ^ permalink raw reply [flat|nested] 16+ messages in thread
* How to set the stack size on GNAT (Follow-up) 2005-08-05 0:55 STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW Adaddict 2005-08-05 1:21 ` Adaddict @ 2005-08-06 11:21 ` Adaddict 2005-08-07 12:33 ` Please, help me Adaddict ` (2 more replies) 2005-08-09 22:05 ` Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large Adaddict 2 siblings, 3 replies; 16+ messages in thread From: Adaddict @ 2005-08-06 11:21 UTC (permalink / raw) Ok, I read the posts below talking about this error and they all menction about setting the stack size. They menction different ways to do it: 1. package Linker is for Default_Switches ("ada") use ("-g", "-Xlinker stack=0x10000000,0x10000000"); end Linker; 2. -Xlstack= 10485760 3. --Xlinker --stack=4000000,4000000 4. $ gnatlink hello -Xlinker --stack=0x10000,0x1000 5. $ gnatlink hello -Wl,--stack=0x1000000 Creating the linker package (1) I was getting a compilation error with it ("missing use"). Using the other 4 ways in the command prompt by writing gnatlink <my main program filename here> and the 4 other options I was getting the message "gnatlink: Failed to open binder output". Could anyone tell me what am I doing wrong and what should I write exactly? Thank you everyone. Forgive me for such a newbie question. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Please, help me. 2005-08-06 11:21 ` How to set the stack size on GNAT (Follow-up) Adaddict @ 2005-08-07 12:33 ` Adaddict 2005-08-07 14:11 ` Jeff Creem 2005-08-07 15:31 ` How to set the stack size on GNAT (Follow-up) John B. Matthews 2005-08-07 16:15 ` (Follow-up) Adaddict 2 siblings, 1 reply; 16+ messages in thread From: Adaddict @ 2005-08-07 12:33 UTC (permalink / raw) I know this questions must seem stupid (I'm sure they really are), but I'm getting desesperated because I'm not getting those ways of setting the stack size to work. Sorry for being a nuisance. Regards. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Please, help me. 2005-08-07 12:33 ` Please, help me Adaddict @ 2005-08-07 14:11 ` Jeff Creem 2005-08-07 14:51 ` Increasing stack size (was: Please, help me.) Larry Kilgallen 2005-08-07 15:16 ` Please, help me Ludovic Brenta 0 siblings, 2 replies; 16+ messages in thread From: Jeff Creem @ 2005-08-07 14:11 UTC (permalink / raw) Adaddict wrote: > I know this questions must seem stupid (I'm sure they really are), but I'm > getting desesperated because I'm not getting those ways of setting the > stack size to work. > > Sorry for being a nuisance. > > Regards. > I've always tried to find ways of avoiding having the main task require a large stack. On some OSs, there is no good way to do it at link time at all. Is there any way you can restructure your code so you don't need a large stack (e.g. If there is a set of large variables within the procedure blah is large variables begin end; then moving all of the large variables to a package spec that the procedure blah withs will reduce the stack space. If it is the sum of lots of littler things through the program then perhaps using the storage_size attribute on a new task that does all of the real work of the program (with the main thread just terminating) will work. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Increasing stack size (was: Please, help me.) 2005-08-07 14:11 ` Jeff Creem @ 2005-08-07 14:51 ` Larry Kilgallen 2005-08-07 15:16 ` Please, help me Ludovic Brenta 1 sibling, 0 replies; 16+ messages in thread From: Larry Kilgallen @ 2005-08-07 14:51 UTC (permalink / raw) In article <97GdnZ2dnZ1c-rnynZ2dnRqLa9-dnZ2dRVn-y52dnZ0@comcast.com>, Jeff Creem <jcreem@yahoo.com> writes: > I've always tried to find ways of avoiding having the main task require > a large stack. On some OSs, there is no good way to do it at link time > at all. On VMS it defaults to "unlimited" (except by process quotas). ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Please, help me. 2005-08-07 14:11 ` Jeff Creem 2005-08-07 14:51 ` Increasing stack size (was: Please, help me.) Larry Kilgallen @ 2005-08-07 15:16 ` Ludovic Brenta 1 sibling, 0 replies; 16+ messages in thread From: Ludovic Brenta @ 2005-08-07 15:16 UTC (permalink / raw) Jeff Creem <jcreem@yahoo.com> writes: [...] > If there is a set of large variables within the > > procedure blah is > large variables > > begin > > end; > > then moving all of the large variables to a package spec that the > procedure blah withs will reduce the stack space. > > If it is the sum of lots of littler things through the program then > perhaps using the storage_size attribute on a new task that does all > of the real work of the program (with the main thread just > terminating) will work. I have observed that array or record aggregates tend to be allocated on the stack, too. Array aggregates are particularly surprising since they're easy to replace with loops. For example: procedure Proc is type T is array (1 .. 100_000) of Integer; A : T; begin A := (others => 42); end Proc; allocates two large arrays on the stack (A and the aggregate) with some compilers I've used. In contrast: procedure Proc is type T is array (1 .. 100_000) of Integer; A : T; begin for J in A'Range loop A (J) := 42; end loop; end Proc; allocates just one array on the stack. Back on topic, setting the stack size depends on the target operating system and on the host linker. There are even situations where it is not possible to set the stack size at all. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: How to set the stack size on GNAT (Follow-up) 2005-08-06 11:21 ` How to set the stack size on GNAT (Follow-up) Adaddict 2005-08-07 12:33 ` Please, help me Adaddict @ 2005-08-07 15:31 ` John B. Matthews 2005-08-07 16:15 ` (Follow-up) Adaddict 2 siblings, 0 replies; 16+ messages in thread From: John B. Matthews @ 2005-08-07 15:31 UTC (permalink / raw) In article <2db7e95053c018032e212a9f7c2c614d@localhost.talkaboutprogramming.com>, "Adaddict" <adaddict@hotmail.com> wrote: > 2. -Xlstack=10485760 I think I proposed this one. It worked with GNAT 3.15 on Mac OS 9 with MachTen or CodeBuilder. IIRC, the default stack size was just a few kilobytes, so adjusting the stack size was sometimes hard to avoid. > Could anyone tell me what am I doing wrong and what > should I write exactly? On Mac OS X, this should set the stack to 8 megabytes (the default): gnatmake -f stack_test -largs --stack=0x800000 But you have to set "ulimit -s <decimal blocks of 1024 bytes>" in the shell to make it work: $ ulimit -s 8192 Here's my test program: with Ada.Text_IO; procedure Stack_Test is Megabyte : constant Positive := 1024 * 1024; type Block is array (0 .. Megabyte - 1) of Character; procedure Allocate_Stack (N : Positive) is Local : Block := (others => Character'Val(0)); begin Ada.Text_IO.Put_Line (N'Img); Allocate_Stack(N + 1); end; begin Allocate_Stack(1); end Stack_Test; By default, the program dies after seven levels of recursion, as expected. With "ulimit -s 16384" I get 15 levels before segmentation fault. What OS are you using? -- John jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ ^ permalink raw reply [flat|nested] 16+ messages in thread
* (Follow-up) 2005-08-06 11:21 ` How to set the stack size on GNAT (Follow-up) Adaddict 2005-08-07 12:33 ` Please, help me Adaddict 2005-08-07 15:31 ` How to set the stack size on GNAT (Follow-up) John B. Matthews @ 2005-08-07 16:15 ` Adaddict 2005-08-07 17:59 ` (Follow-up) Jeffrey Carter 2 siblings, 1 reply; 16+ messages in thread From: Adaddict @ 2005-08-07 16:15 UTC (permalink / raw) Thank you for the replies. I'm using Windows XP SP2, GNAT 3.15p and Ada GIDE. The aplication has to work on Win XP. The function that causes this error is called from the main task, but the big variable is local from that function. I'll write a simple version of the function: procedure Search_str (FileAccess : in Handle; Query : in string; Results : out Integer) is mbi : Memory_Basic_Information; lpPos : uinteger; lPos : integer; CalcPos : uinteger; max : uinteger; length : constant integer := Query'last; begin Results := 0; lpPos := Min_Pos; max := Max_Pos; while lpPos < max loop mbi.RegionSize := 0; mbi := Query_Pos (FileAccess, lpPos); if ((mbi.C_Type = PRIVATE_DATA) and (mbi.State = COMMIT_DATA)) then if mbi.RegionSize > 0 then declare sBuffer : string (1..integer(mbi.RegionSize)); begin sBuffer := Read(FileAccess, mbi.BasePos, mbi.RegionSize); lPos := instr (Query, length, sBuffer); if lpos > 0 then CalcAddress := address_to_uinteger(mbi.BaseAddress) + uinteger(lPos); Put_Line ("Search string was found at position" & uInteger'image(CalcPos) & "."); Results := Results+1; end if; end; end if; end if; lpPos := mbi.BasePos + mbi.RegionSize; end loop; end Search_str; Thankyou everyone again. Kind regards. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: (Follow-up) 2005-08-07 16:15 ` (Follow-up) Adaddict @ 2005-08-07 17:59 ` Jeffrey Carter 2005-08-07 20:49 ` (Follow-up) Adaddict 0 siblings, 1 reply; 16+ messages in thread From: Jeffrey Carter @ 2005-08-07 17:59 UTC (permalink / raw) Adaddict wrote: > > procedure Search_str (FileAccess : in Handle; Query : in string; > Results : out Integer) is ... > length : constant integer := Query'last; OT, but just curious. What happens when I call this with Query : String (10_001 .. 10_010); as the actual for Query? Query'Last = 10_010; Query'Length = 10. -- Jeff Carter "I'm a lumberjack and I'm OK." Monty Python's Flying Circus 54 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: (Follow-up) 2005-08-07 17:59 ` (Follow-up) Jeffrey Carter @ 2005-08-07 20:49 ` Adaddict 0 siblings, 0 replies; 16+ messages in thread From: Adaddict @ 2005-08-07 20:49 UTC (permalink / raw) Nothing much as all the strings that I used as queries are indexed from 1. However I changed it. I hope to get over this nasty error soon... Thank you for your attention. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large 2005-08-05 0:55 STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW Adaddict 2005-08-05 1:21 ` Adaddict 2005-08-06 11:21 ` How to set the stack size on GNAT (Follow-up) Adaddict @ 2005-08-09 22:05 ` Adaddict 2005-08-10 4:56 ` Jeff Creem 2 siblings, 1 reply; 16+ messages in thread From: Adaddict @ 2005-08-09 22:05 UTC (permalink / raw) Ok, I changed the way of declaring the large variable, and now I'm getting a different but nicer looking error: raised STORAGE_ERROR : helper.adb:386 object too large The variable is a string (1..n), where n it's the number of bytes that are going to be read from certain region. The region size can be of some MB, so I would be easy for me if I could use a variable from this size. How could I do it? And if I can't do it what alternative would you recomend me? Thanks a lot to everyone for your replies and help. Regards. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large 2005-08-09 22:05 ` Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large Adaddict @ 2005-08-10 4:56 ` Jeff Creem 2005-08-10 17:44 ` Robert A Duff 0 siblings, 1 reply; 16+ messages in thread From: Jeff Creem @ 2005-08-10 4:56 UTC (permalink / raw) Adaddict wrote: > Ok, I changed the way of declaring the large variable, and now I'm getting > a different but nicer looking error: raised STORAGE_ERROR : helper.adb:386 > object too large > > The variable is a string (1..n), where n it's the number of bytes that are > going to be read from certain region. The region size can be of some MB, so > I would be easy for me if I could use a variable from this size. How could > I do it? And if I can't do it what alternative would you recomend me? > > Thanks a lot to everyone for your replies and help. > > Regards. > It is hard to tell without looking at the context what the best solution is. If the string is fairly local then an access type can probably be used without worrying too much about creating leak by doing something based on.... type Access_String is access String; procedure Free is new Unchecked_Deallocation(String, Access_String); .. .. .. code that is getting N begin Region_Data := new String(1 .. N); Fill_In_Data_Into_Region_Data Call_Existing_Code_THat_Wants_String(Region_Data.all); Free(Region_Data); exceptioon when others => Free(Region_Data); raise; end; ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large 2005-08-10 4:56 ` Jeff Creem @ 2005-08-10 17:44 ` Robert A Duff 0 siblings, 0 replies; 16+ messages in thread From: Robert A Duff @ 2005-08-10 17:44 UTC (permalink / raw) Jeff Creem <jcreem@yahoo.com> writes: > .. code that is getting N > > begin > Region_Data := new String(1 .. N); > Fill_In_Data_Into_Region_Data > > Call_Existing_Code_THat_Wants_String(Region_Data.all); > > Free(Region_Data); > > exceptioon > when others => > Free(Region_Data); > raise; > end; If the Call_Existing_Code_THat_Wants_String part can be aborted, then you should wrap the memory management in a controlled type, so an abort won't cause a storage leak. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* PLEASE HELP ME @ 1998-10-21 0:00 DENIS 1998-10-22 0:00 ` Tucker Taft 0 siblings, 1 reply; 16+ messages in thread From: DENIS @ 1998-10-21 0:00 UTC (permalink / raw) Please , I do not have any clue in Ada95, but I do have to know how to determine the order parameters are put on the stack. Please write as soons is possible. This is my email : datodia@hotmail.com ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: PLEASE HELP ME 1998-10-21 0:00 PLEASE HELP ME DENIS @ 1998-10-22 0:00 ` Tucker Taft 0 siblings, 0 replies; 16+ messages in thread From: Tucker Taft @ 1998-10-22 0:00 UTC (permalink / raw) DENIS (denis23@ix.netcom.com) wrote: : Please , I do not have any clue in Ada95, but I do have to know how to : determine the order parameters are put on the stack. : Please write as soons is possible. This is implementation-dependent. Perhaps it would be in the documentation provided by the Ada vendor, in the area of interfacing with assembly language. Furthermore, note that these days, not all parameters are passed on the stack. For most RISC machines, at least a few parameters are passed in registers. You could write your own test case using 'Address which might tell you something. E.g.: with system.storage_elements; use system.storage_elements; with ada.text_io; use ada.text_io; procedure stack_order is procedure p(A, B, C, D, E, F, G, H, I, J : Integer) is begin put_line("A'address = " & Integer_Address'Image(To_Integer(A'Address))); put_line("B'address = " & Integer_Address'Image(To_Integer(B'Address))); put_line("C'address = " & Integer_Address'Image(To_Integer(C'Address))); ... end p; begin p(1,2,3,4,5,6,7,8,9,10); end stack_order; : This is my email : datodia@hotmail.com -- -Tucker Taft stt@inmet.com http://www.inmet.com/~stt/ Intermetrics, Inc. Burlington, MA USA An AverStar Company ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2005-08-10 17:44 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-08-05 0:55 STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW Adaddict 2005-08-05 1:21 ` Adaddict 2005-08-06 11:21 ` How to set the stack size on GNAT (Follow-up) Adaddict 2005-08-07 12:33 ` Please, help me Adaddict 2005-08-07 14:11 ` Jeff Creem 2005-08-07 14:51 ` Increasing stack size (was: Please, help me.) Larry Kilgallen 2005-08-07 15:16 ` Please, help me Ludovic Brenta 2005-08-07 15:31 ` How to set the stack size on GNAT (Follow-up) John B. Matthews 2005-08-07 16:15 ` (Follow-up) Adaddict 2005-08-07 17:59 ` (Follow-up) Jeffrey Carter 2005-08-07 20:49 ` (Follow-up) Adaddict 2005-08-09 22:05 ` Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large Adaddict 2005-08-10 4:56 ` Jeff Creem 2005-08-10 17:44 ` Robert A Duff -- strict thread matches above, loose matches on Subject: below -- 1998-10-21 0:00 PLEASE HELP ME DENIS 1998-10-22 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox