STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW

STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW

[Adaddict]

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.

Re: STORAGE_ERROR : EXCEPTION_STACK_OVERFLOW

[Adaddict]

Sorry, just after posting this I noticed the other thread about this error.
My apologises.

How to set the stack size on GNAT (Follow-up)

[Adaddict]

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.

Please, help me.

[Adaddict]

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.

Re: Please, help me.

[Jeff Creem]

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.

Re: Increasing stack size (was: Please, help me.)

[Larry Kilgallen]

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).

Re: Please, help me.

[Ludovic Brenta]

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.

Re: How to set the stack size on GNAT (Follow-up)

[John B. Matthews]

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/

(Follow-up)

[Adaddict]

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.

Re: (Follow-up)

[Jeffrey Carter]

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

Re: (Follow-up)

[Adaddict]

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.

Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large

[Adaddict]

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.

Re: Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large

[Jeff Creem]

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;

Re: Follow up 2: raised STORAGE_ERROR : helper.adb:386 object too large

[Robert A Duff]

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