Error: "could not understand bounds information on packed array"

Error: "could not understand bounds information on packed array"

[Dennis Hoppe]

Hi,

I am getting the following error message while executing my program:

Execution terminated by unhandled exception
Exception name: STORAGE_ERROR
Message: stack overflow

By use of gdb, I am getting some more useful information like

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3fffd0
0x0000000100027cde in my_procedure (input_a=warning: could not 
understand bounds information on packed array
can't unpack array
, input_b=warning: could not understand bounds information on packed 
array can't unpack array
, input_c=can't unpack array
, input_d=can't unpack array
, input_e=0, output=) at my_package.adb:143
143	    procedure myprocedure (input_a : in     Bit_Field;


I am using the following data types ...

type Word is mod 2**64;
for Word'Size use 64;
pragma Volatile(Word);

type Bit is new Natural range 0 .. 1;
type Bit_Number is new Natural range 0 .. Word'Size - 1;
type Bit_Field is array (Bit_Number) of Boolean;

for Bit_Field'Component_Size use 1;

... and conversions ...

function To_Bit_Field is
   new Ada.Unchecked_Conversion (Source => Word, Target => Bit_Field);

function To_Word is
   new Ada.Unchecked_Conversion (Source => Bit_Field, Target => Word);


Snippet:

procedure my_procedure
   (input_a : in     Bit_Field;
    input_b : in     Bit_Field;
    input_c : in out Bit_Field;
    input_d : in out Bit_Field;
    index   : in     Natural;
    output  : in out Word_Vector.Vector) is
begin
   if index = Bit_Field'Length then
     Word_Vector.Append (output, To_Word(input_c));
   else
     -- do something
     -- recursive call
     my_procedure(input_a, input_b, input_c, input_d, index+1, output);
   end if;
end my_procedure;


Currently, I am appending exactly eight elements to the vector. So, no 
Storage_Error could be raised based on too much elements.


The procedure, which causes the error is recursive. A new Word will be 
constructed bitwise and in the end, the Word will be appended to a vector.

First, I thought, the error may be raised due to the unchecked 
conversions (cf. "can't unpack array"). However, I am using the 
unchecked conversion just once in the termination clause. Uncommenting 
the conversion does not help.

Then, I am stumbled upon "EXC_BAD_ACCESS, Could not access memory". 
Additionally, the error message differs from time to time (if I compile 
with or without optimization, with or without -fstack-check):

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3fffe0
0x00007fff82d91b28 in szone_malloc ()
(gdb) backtrace
#0  0x00007fff82d91b28 in szone_malloc ()
#1  0x00007fff82d91aef in malloc_zone_malloc ()
#2  0x00007fff82d91a80 in malloc ()
#3  0x000000010006da5f in __gnat_malloc ()
#4  0x0000000100025f48 in word_vector.insert (container=, before=0, 
new_item=16, count=<value temporarily unavailable, due to 
optimizations>) at a-convec.adb:829
#5  0x0000000100026488 in word_vector.append (container=, 
new_item=9223654062804208200, count=1598043600) at a-convec.adb:316


This may be caused in the termination clause, where I try to append the 
new Word to a vector. It is interesting, that call #5 and #4 has another 
value for "new_item", although insert is called in the body of append.

At the moment, I am wondering, if my computer has some memory issues.


I know, the problem is hard to understand. I would like to provide a 
minimal code snippet to demonstrate the failure, but the whole program 
is very complex. I tried to take the parameters given by the debugger -- 
recovered by means of backtracing -- directly as input to the procedure. 
But no error occurs at all, if I call the problematic procedure solely.


Best regards,
   Dennis Hoppe

Re: Error: "could not understand bounds information on packed array"

[Dennis Hoppe]

Some additional information:



I should add, that the recursive procedure will be called from another 
recursive procedure, too. I commented the calls to "my_procedure" (see 
the previous post) out and still getting memory access problems:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00007fff5f3ffb60
0x000000010005154d in grete.darxplorer.recursive_call 
(differentials_graph=Cannot access memory at address 0x7fff5f3ffea8
) at toolbox-grete.adb:16
16		procedure Recursive_Call (Value : in out Object;
(gdb) backtrace
#0  0x000000010005154d in recursive_call (value=Cannot access memory at 
address 0x7fff5f3ffea8
) at my_package.adb:16

Recursive_Call is the outer procedure, that calls "my_procedure". 
Recursive_Call is recursive, too.

The so called "Object" is in fact a directed graph, which gets in each 
recursion new vertices and edges. The graph originates from Ada Booch95.

The problem seems to not rest upon the bit-operations mentioned before.

Re: Error: "could not understand bounds information on packed array"

[Per Sandberg]

Well.
As you say stacks will be exhausted  sooner or later if you are writing 
indefinite recursive algorithms.
And of course its possible to set the upper stack limit.
The simplest way is to add "pragma Linker_Options" in your main.
As i did in your sample.
/Per

----------------
with Ada.Text_IO; use Ada.Text_IO;
procedure Testsuite is
    pragma Linker_Options ("-Wl,--stack=0x4000000");

    procedure Recursive_Call (Index : in out Integer) is
    begin
       Index := Index + 1;
       Ada.Text_IO.Put_Line (Integer'Image (Index));
       Recursive_Call (Index);
    end Recursive_Call;

begin
    declare
       I : Integer := 0;
    begin
       Recursive_Call (I);
       Ada.Text_IO.Put_Line (Integer'Image (I));
    end;
end Testsuite;
/Per

Dennis Hoppe wrote:
> Now, I am sure it is "just" a recursion issue. The following test 
> terminates after just 87.354 iterations:
> 
> 
> with Ada.Text_IO; use Ada.Text_IO;
> 
> procedure Testsuite is
> 
>   procedure Recursive_Call (Index : in out Integer) is
>   begin
>     Index := Index + 1;
>     Ada.Text_IO.Put_Line (Integer'Image (Index));
>     Recursive_Call (Index);
>   end Recursive_Call;
> 
> begin
>   declare
>     I : Integer := 0;
>   begin
>     Recursive_Call (I);
>     Ada.Text_IO.Put_Line (Integer'Image (I));
>   end;
> end Testsuite;
> 
> 
> Output:
> 
>  [..]
>  87354
> 
> raised STORAGE_ERROR : stack overflow
> 
> Well, I didn't provide a suitable base case for termination. I just 
> wanted do find out the upper bound of recursive calling.
> 
> For me, 87.354 seems to be a very low upper bound of recursion. An 
> adapted version in Java runs 519.045 recursion steps before a 
> StackOverflowError occurs on the same machine.
> 
> It is clear, that I cannot indefinitely call a procedure recursively. 
> Unfortunately, I cannot predict in advance, how many recursion steps
> my program have to proceed. How can I avoid the stack overflow in 
> recursion? Can I influence the upper bound of recursive calls, i.e the 
> size of the run-time stack?
> 
> Thank you,
>   Dennis
> 
> 

Re: Error: "could not understand bounds information on packed array"

[Dennis Hoppe]

Now, I am sure it is "just" a recursion issue. The following test 
terminates after just 87.354 iterations:


with Ada.Text_IO; use Ada.Text_IO;

procedure Testsuite is

   procedure Recursive_Call (Index : in out Integer) is
   begin
     Index := Index + 1;
     Ada.Text_IO.Put_Line (Integer'Image (Index));
     Recursive_Call (Index);
   end Recursive_Call;

begin
   declare
     I : Integer := 0;
   begin
     Recursive_Call (I);
     Ada.Text_IO.Put_Line (Integer'Image (I));
   end;
end Testsuite;


Output:

  [..]
  87354

raised STORAGE_ERROR : stack overflow

Well, I didn't provide a suitable base case for termination. I just 
wanted do find out the upper bound of recursive calling.

For me, 87.354 seems to be a very low upper bound of recursion. An 
adapted version in Java runs 519.045 recursion steps before a 
StackOverflowError occurs on the same machine.

It is clear, that I cannot indefinitely call a procedure recursively. 
Unfortunately, I cannot predict in advance, how many recursion steps
my program have to proceed. How can I avoid the stack overflow in 
recursion? Can I influence the upper bound of recursive calls, i.e the 
size of the run-time stack?

Thank you,
   Dennis

Re: Error: "could not understand bounds information on packed array"

[John B. Matthews]

In article <gvoim5$umb$1@aioe.org>,
 Dennis Hoppe <dennis.hoppe@hoppinet.de> wrote:

> Now, I am sure it is "just" a recursion issue. The following test 
> terminates after just 87.354 iterations:
[...]
> Output:
> 
>   87354

I get 85287 with a stack size of 8192 KiB, ~100 bytes/frame.

[...]
> For me, 87.354 seems to be a very low upper bound of recursion. An 
> adapted version in Java runs 519.045 recursion steps before a 
> StackOverflowError occurs on the same machine.

Each JVM will surely have some default stack size. Mine gives 208369 
for for the smallest permitted heap: -Xms1048576 -Xmx1048576. I would 
not be surprised if the JVM stack frame is smaller.

> It is clear, that I cannot indefinitely call a procedure recursively. 
> Unfortunately, I cannot predict in advance, how many recursion steps 
> my program have to proceed. How can I avoid the stack overflow in 
> recursion? Can I influence the upper bound of recursive calls, i.e 
> the size of the run-time stack?

This is OS dependent. If you are using GNAT, you might check the User's 
Guide:

<http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gnat_ugn_unw/Stack-Overflow-Checking.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Error: "could not understand bounds information on packed array"

[Dennis Hoppe]

Thank you both, John and Per, for your answers. In my opionion, the best 
idea is to transform the recursion into an iterative procedure, because 
I cannot predict, if the stack size will be sufficient - even if I 
specify it manually.

Nevertheless, it is nice to know, how to alter the stack size in Ada.

Best regards,
   Dennis