Re: GNAT implementation bug? (or my code)

Re: GNAT implementation bug? (or my code)

[Tucker Taft]

Stephen Arnold wrote:
> 
> Howdy all:
> 
> I'm just learning Ada, so this could easily be own code barfing, but it
> seems like there's a bug in GNAT (Linux or win32).  I'm using 3.12p on
> both platforms (win9x and RH6.1), and the code seems to run fine on
> winNT as well.
> 
> This is a homework assignment, and it passes both my test driver and the
> instructor's test driver on win32, however, I get the following error on
> my RH6.1 (kernel 2.2.12, stock install) partition:
> ...

It compiles and works fine on our Solaris AdaMagic Ada95 compiler.
See the output below.

One possibility might be that the default stack size on the
GNAT run-time system on RH6.1 is insufficient for your test.

> ...
> > Dequeued item:  4
> > Dequeued item:  3
> > Something is terribly wrong. There was as unanticipated exception:
> > STORAGE_ERROR
> > stack overflow (or erroneous memory access)
-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA

----------- output from q_test ---------

Testing Count and Empty.
Creating empty queues...
Count(A) =  0
Count(B) =  0
Count(C) =  0

Checking empty status...
Empty(A) = TRUE
Empty(B) = TRUE
Empty(C) = TRUE
Empty(D) = TRUE

Adding known values to A and dequeueing them.
Dequeued item:  17
Dequeued item:  13
Dequeued item:  11
Dequeued item:  10
Dequeued item:  8
Dequeued item:  4
Dequeued item:  3
Dequeued item:  1

Testing Enqueue, Dequeue, and Front.
Filling other queues with 8 random integers...

Checking contents of B.
The number queued was:  1
The front of the queue is:  1
The number queued was:  16
The front of the queue is:  16
The number queued was:  14
The front of the queue is:  16
The number queued was:  12
The front of the queue is:  16
The number queued was:  8
The front of the queue is:  16
The number queued was:  3
The front of the queue is:  16
The number queued was:  15
The front of the queue is:  16
The number queued was:  10
The front of the queue is:  16

Dequeueing two values of B.
The first number dequeued was:  16
The second number dequeued was:  15

Count(A) =  0
Count(B) =  6
Count(C) =  8
Count(D) =  8

Is B = C?  FALSE
Is B = B?  TRUE
Is C = D?  FALSE

Clearing D.
Count(D) =  0

Beginning exception tests...
Getting item from front of D...
The exception was: Q_Test.Q.Underflow
The exception message is: Error using Front.  Queue is empty.
Front test passed.

Dequeueing item of D.
The exception was: Q_Test.Q.Underflow
The exception message is: Error using Dequeue.  Queue is empty.
Dequeue test passed.

Re: GNAT implementation bug? (or my code)

[Stephen Arnold]

Tucker Taft wrote:
> 
> It compiles and works fine on our Solaris AdaMagic Ada95 compiler.
> See the output below.
> 
> One possibility might be that the default stack size on the
> GNAT run-time system on RH6.1 is insufficient for your test.
> 
> > ...
> > > Dequeued item:  4
> > > Dequeued item:  3
> > > Something is terribly wrong. There was as unanticipated exception:
> > > STORAGE_ERROR
> > > stack overflow (or erroneous memory access)

> ----------- output from q_test ---------
> [snip]
> Adding known values to A and dequeueing them.
> Dequeued item:  17
> Dequeued item:  13
> Dequeued item:  11
> Dequeued item:  10
> Dequeued item:  8
> Dequeued item:  4
> Dequeued item:  3
> Dequeued item:  1
> 
> Testing Enqueue, Dequeue, and Front.
> Filling other queues with 8 random integers...

Erm...  With a little help, I found the problem (and posted on my other
thread) and it seems like my code should've bombed on Solaris too (as I
was trying to free the same memory twice -> Remove calls Clear, which
frees Orphan and sets the list pointers to null, then it jumps back to
Remove, which tried to free Orphan again).  Any thoughts?

(thanks for trying my code, though :)

Steve

Re: GNAT implementation bug? (or my code)

[Robert Dewar]

In article <38F7935B.22173D26@ensco.com>,
  Stephen Arnold <arnold.steve@ensco.com> wrote:
> Erm...  With a little help, I found the problem (and posted on
my other
> thread) and it seems like my code should've bombed on Solaris
too (as I
> was trying to free the same memory twice -> Remove calls
Clear, which
> frees Orphan and sets the list pointers to null, then it jumps
back to
> Remove, which tried to free Orphan again).  Any thoughts?
>
> (thanks for trying my code, though :)


First, don't be too quick to assume that there is a compiler
or run-time bug (this advice is also directed to Tucker :-) :-)

Second, investigate tools that help you make sure your memory
management is correct. GNAT comes with such tools (investigate
gnatmem), and I assume other Ada 95 technologies have similar
capbilities.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: GNAT implementation bug? (or my code)

[Simon Wright]

Robert Dewar <robert_dewar@my-deja.com> writes:

> Second, investigate tools that help you make sure your memory
> management is correct. GNAT comes with such tools (investigate
> gnatmem), and I assume other Ada 95 technologies have similar
> capbilities.

In this case, gnatmem didn't help. However, using System.Debug_Pools.Debug_Pool
did the job:

   type List_Element ;
   type List_Element_Ptr is access list_element ;

   Pool : System.Debug_Pools.Debug_Pool;
   for List_Element_Ptr'Storage_Pool use Pool;

and then

pogner[27]$ gdb q_test
[...]
(gdb) b exception
Breakpoint 1 at 0x80507fd: file a-except.adb, line 922.
(gdb) run
[...]
Breakpoint 1, 0x804ab1b in q_test.q.lm.remove (list=(head => 0x0, tail => 0x0, 
      cursor => 0x0, count => 0, traversing => false))
    at dynamic_list_manager.adb:160
160            Free(Orphan) ;
(gdb) p orphan.all
$3 = (prev => 0xefbeadde, data => -272716322, next => 0xefbeadde)

(the 0xefbeadde are the Intel versions of the classic deadbeef pattern, btw).