* Error: "could not understand bounds information on packed array"
@ 2009-05-29 0:55 Dennis Hoppe
2009-05-29 1:13 ` Dennis Hoppe
0 siblings, 1 reply; 6+ messages in thread
From: Dennis Hoppe @ 2009-05-29 0:55 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Error: "could not understand bounds information on packed array"
2009-05-29 0:55 Error: "could not understand bounds information on packed array" Dennis Hoppe
@ 2009-05-29 1:13 ` Dennis Hoppe
2009-05-29 11:58 ` Dennis Hoppe
0 siblings, 1 reply; 6+ messages in thread
From: Dennis Hoppe @ 2009-05-29 1:13 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Error: "could not understand bounds information on packed array"
2009-05-29 1:13 ` Dennis Hoppe
@ 2009-05-29 11:58 ` Dennis Hoppe
2009-05-29 11:56 ` Per Sandberg
2009-05-29 13:02 ` John B. Matthews
0 siblings, 2 replies; 6+ messages in thread
From: Dennis Hoppe @ 2009-05-29 11:58 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Error: "could not understand bounds information on packed array"
2009-05-29 11:58 ` Dennis Hoppe
@ 2009-05-29 11:56 ` Per Sandberg
2009-05-29 13:02 ` John B. Matthews
1 sibling, 0 replies; 6+ messages in thread
From: Per Sandberg @ 2009-05-29 11:56 UTC (permalink / raw)
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
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Error: "could not understand bounds information on packed array"
2009-05-29 11:58 ` Dennis Hoppe
2009-05-29 11:56 ` Per Sandberg
@ 2009-05-29 13:02 ` John B. Matthews
2009-05-29 13:46 ` Dennis Hoppe
1 sibling, 1 reply; 6+ messages in thread
From: John B. Matthews @ 2009-05-29 13:02 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Error: "could not understand bounds information on packed array"
2009-05-29 13:02 ` John B. Matthews
@ 2009-05-29 13:46 ` Dennis Hoppe
0 siblings, 0 replies; 6+ messages in thread
From: Dennis Hoppe @ 2009-05-29 13:46 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2009-05-29 13:46 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-29 0:55 Error: "could not understand bounds information on packed array" Dennis Hoppe
2009-05-29 1:13 ` Dennis Hoppe
2009-05-29 11:58 ` Dennis Hoppe
2009-05-29 11:56 ` Per Sandberg
2009-05-29 13:02 ` John B. Matthews
2009-05-29 13:46 ` Dennis Hoppe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox