Possible GNAT bug, but wanted to see if it was a violtion of the RM

Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Jere]

It took a while, but I got a small contrived example to get this bug.
The gist:

Windows 10
GNAT GPL 2017
FSF GNAT 7.2 hosted on mingw64 for x86_64

I was working on some code that used composition to build up some
components.  I was adding iteration to the top level component using
an internal component as the basis for it.  I started running into
runtime error when I did a "for E of Container loop" construct.  The
exceptions happened at the end of the program and raised Program_Error
mentioning an exception in Finalize/Adjust.  Below is a very contrived
example, but I wanted a minimal compilable example to provide.

I'm certain there is a GNAT bug here, as merely changing how I call a
function (changing from object.function to package.function(object)),
removes the runtime error.  On the flip side, I am using anonymous
access types (as required for the indexing operations), so I might
be misusing those accidentally.  My question is if this is legal
code (and a bug) or not.  I don't know anonymous access types well 
enough to know for sure.

**********************************************************************
with Ada.Text_IO; use Ada.Text_IO;
with Ada.Containers.Vectors;

procedure Main is

   package Composite is
      
      package Vectors is new Ada.Containers.Vectors(Positive,Integer);
      
      type Instance is tagged limited record
         Vector : Vectors.Vector;
      end record
         with
            Default_Iterator  => Iterate,
            Constant_Indexing => Constant_Reference,
            Iterator_Element  => Integer;
      
      type Constant_Reference_Type
         (Element : not null access constant Integer)
      is limited null record
         with Implicit_Dereference => Element;
      
      function Constant_Reference
         (Container : aliased Instance;
          Cursor    : Vectors.Cursor)
          return Constant_Reference_Type
      -- This version causes a runtime error:
      -- raised PROGRAM_ERROR : main.adb:4 finalize/adjust raised exception
      is (Element =>
             Container.Vector.Constant_Reference(Cursor).Element);
--        -- This version works and does not causes a runtime error
--        is (Element =>
--               Vectors.Constant_Reference(Container.Vector,Cursor).Element);
      
      
      function Iterate
         (Container : Instance)
          return Vectors.Vector_Iterator_Interfaces.Reversible_Iterator'Class
      is (Container.Vector.Iterate);
      
   end Composite;
  
   Container : Composite.Instance;
   
begin
   
   for I in 1..5 loop
      Container.Vector.Append(I);
   end loop;
   
   for E of Container loop
      Put_Line(Integer'Image(E));
   end loop;

end Main;

**********************************************************************

Output:
main.exe
 1
 2
 3
 4
 5

raised PROGRAM_ERROR : main.adb:4 finalize/adjust raised exception
[2018-02-22 21:25:48] process exited with status 1, elapsed time: 00.20s

Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Simon Wright]

I don't know if it helps, but running under the debugger (GCC 8.0.1,
macOS) show the first exception is

Catchpoint 1, PROGRAM_ERROR (Main.Composite.Vectors.Implementation.TC_Check: attempt to tamper with cursors) at __gnat_debug_raise_exception (
    e=0x10003eaa0 <program_error>, message=...) at s-excdeb.adb:40
40	s-excdeb.adb: No such file or directory.
(gdb) bt
#0  __gnat_debug_raise_exception (e=0x10003eaa0 <program_error>, message=...)
    at s-excdeb.adb:40
#1  0x0000000100011cdd in ada__exceptions__complete_occurrence (x=0x1003020f0)
    at a-except.adb:931
#2  0x0000000100011ced in ada__exceptions__complete_and_propagate_occurrence (
    x=0x1003020f0) at a-except.adb:942
#3  0x0000000100011d42 in __gnat_raise_exception (
    e=0x10003eaa0 <program_error>, message=...) at a-except.adb:984
#4  0x0000000100006f27 in main.composite.vectors.implementation.tc_check ()
#5  0x0000000100008e11 in main.composite.vectors.finalize ()
#6  0x000000010000fe19 in main__composite__instanceDF.7589 ()
#7  0x0000000100010250 in main___finalizer.4676 ()
#8  0x0000000100006c20 in main ()

Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Jere]

On Friday, February 23, 2018 at 4:17:02 AM UTC-5, Simon Wright wrote:
> I don't know if it helps, but running under the debugger (GCC 8.0.1,
> macOS) show the first exception is
> 
> Catchpoint 1, PROGRAM_ERROR (Main.Composite.Vectors.Implementation.TC_Check: attempt to tamper with cursors) at __gnat_debug_raise_exception (
>     e=0x10003eaa0 <program_error>, message=...) at s-excdeb.adb:40
> 40	s-excdeb.adb: No such file or directory.
> (gdb) bt
> #0  __gnat_debug_raise_exception (e=0x10003eaa0 <program_error>, message=...)
>     at s-excdeb.adb:40
> #1  0x0000000100011cdd in ada__exceptions__complete_occurrence (x=0x1003020f0)
>     at a-except.adb:931
> #2  0x0000000100011ced in ada__exceptions__complete_and_propagate_occurrence (
>     x=0x1003020f0) at a-except.adb:942
> #3  0x0000000100011d42 in __gnat_raise_exception (
>     e=0x10003eaa0 <program_error>, message=...) at a-except.adb:984
> #4  0x0000000100006f27 in main.composite.vectors.implementation.tc_check ()
> #5  0x0000000100008e11 in main.composite.vectors.finalize ()
> #6  0x000000010000fe19 in main__composite__instanceDF.7589 ()
> #7  0x0000000100010250 in main___finalizer.4676 ()
> #8  0x0000000100006c20 in main ()

Thanks!  That confirms my initial suspicion of it being related to tamper 
checks, but I can't figure out how.  I looked through the GNAT code and 
saw how they locked it in the Constant_Reference function, but I can't 
for the life of me figure out how calling it using:

   Package.Operation(Object,Params).Discriminant

would work differently than

   Object.Operation(Params).Discriminant 

for that function call.  I would have assumed that both styles would 
produce the same code.  And even so, I wasn't able to figure out why
the busy lock for the tamper check wasn't released in the case that
generates the exception.

Is it safe to say I am not doing something illegal at least?  I'm
copying one anonymous access type into another (in order to propagate
the inner objects reference to the external object for iteration).
I feel like I remember someone saying you shouldn't be able to copy
anonymous access types, but perhaps in this case it is ok?

I'm gonna submit this to GNAT (I think) because I feel either way it is
a bug.  Either I am doing something legal that results in bad code or
I am doing something illegal and it isn't being caught by the compiler
or runtime at the right spot (I think).

Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Jere]

On Friday, February 23, 2018 at 4:17:02 AM UTC-5, Simon Wright wrote:
> I don't know if it helps, but running under the debugger (GCC 8.0.1,
> macOS) show the first exception is
> 
> Catchpoint 1, PROGRAM_ERROR (Main.Composite.Vectors.Implementation.TC_Check: attempt to tamper with cursors) at __gnat_debug_raise_exception (
>     e=0x10003eaa0 <program_error>, message=...) at s-excdeb.adb:40
> 40	s-excdeb.adb: No such file or directory.
> (gdb) bt
> #0  __gnat_debug_raise_exception (e=0x10003eaa0 <program_error>, message=...)
>     at s-excdeb.adb:40
> #1  0x0000000100011cdd in ada__exceptions__complete_occurrence (x=0x1003020f0)
>     at a-except.adb:931
> #2  0x0000000100011ced in ada__exceptions__complete_and_propagate_occurrence (
>     x=0x1003020f0) at a-except.adb:942
> #3  0x0000000100011d42 in __gnat_raise_exception (
>     e=0x10003eaa0 <program_error>, message=...) at a-except.adb:984
> #4  0x0000000100006f27 in main.composite.vectors.implementation.tc_check ()
> #5  0x0000000100008e11 in main.composite.vectors.finalize ()
> #6  0x000000010000fe19 in main__composite__instanceDF.7589 ()
> #7  0x0000000100010250 in main___finalizer.4676 ()
> #8  0x0000000100006c20 in main ()

Side question:
I wasn't able to get the GPL debugger to trigger on the exception.  I tried
stepping through the program but the application just exits at the end
without the debug info.  I tried putting an exception handler and break
point in that, but it never catches the exception (so either I am not
allowed to catch Program_Error or the exception happens outside of my
main operation).

How did you get the debugger to provide that info?

Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> I wasn't able to get the GPL debugger to trigger on the exception.  I
> tried stepping through the program but the application just exits at
> the end without the debug info.  I tried putting an exception handler
> and break point in that, but it never catches the exception (so either
> I am not allowed to catch Program_Error or the exception happens
> outside of my main operation).

I just said

   (gdb) catch exception

If this doesn't work - it says

   Your Ada runtime appears to be missing some debugging information.
   Cannot insert Ada exception catchpoint in this configuration.

then invoke gdb with the -readnow switch. This may be a macOS thing, but
see http://sourceware.org/bugzilla/show_bug.cgi?id=11385 .

Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Simon Wright]

Jere <jhb.chat@gmail.com> writes:

> Thanks!  That confirms my initial suspicion of it being related to
> tamper checks, but I can't figure out how.  I looked through the GNAT
> code and saw how they locked it in the Constant_Reference function,
> but I can't for the life of me figure out how calling it using:
>
>    Package.Operation(Object,Params).Discriminant
>
> would work differently than
>
>    Object.Operation(Params).Discriminant 
>
> for that function call.

Compiling with -gnatG (to list an Ada-like representation of what the
compiler has transformed your code into before it starts
optimisation/code generation) shows that the Package.Operation version
includes some finalization in Operation that's missing in the
Object.Operation version. Looks very like a bug!

Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Jere]

On Sunday, February 25, 2018 at 6:50:46 AM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > I wasn't able to get the GPL debugger to trigger on the exception.  I
> > tried stepping through the program but the application just exits at
> > the end without the debug info.  I tried putting an exception handler
> > and break point in that, but it never catches the exception (so either
> > I am not allowed to catch Program_Error or the exception happens
> > outside of my main operation).
> 
> I just said
> 
>    (gdb) catch exception
> 
> If this doesn't work - it says
> 
>    Your Ada runtime appears to be missing some debugging information.
>    Cannot insert Ada exception catchpoint in this configuration.
> 
> then invoke gdb with the -readnow switch. This may be a macOS thing, but
> see http://sourceware.org/bugzilla/show_bug.cgi?id=11385 .

Thanks!  I've never messed with the debugger at the command level.  I always
just invoked it from GPS using the menus.  I guess I need to start looking
at learning how to work it by hand.

Re: Possible GNAT bug, but wanted to see if it was a violtion of the RM

[Jere]

On Sunday, February 25, 2018 at 6:55:13 AM UTC-5, Simon Wright wrote:
> Jere writes:
> 
> > Thanks!  That confirms my initial suspicion of it being related to
> > tamper checks, but I can't figure out how.  I looked through the GNAT
> > code and saw how they locked it in the Constant_Reference function,
> > but I can't for the life of me figure out how calling it using:
> >
> >    Package.Operation(Object,Params).Discriminant
> >
> > would work differently than
> >
> >    Object.Operation(Params).Discriminant 
> >
> > for that function call.
> 
> Compiling with -gnatG (to list an Ada-like representation of what the
> compiler has transformed your code into before it starts
> optimisation/code generation) shows that the Package.Operation version
> includes some finalization in Operation that's missing in the
> Object.Operation version. Looks very like a bug!

Thank you!  I wasn't aware of that switch.  Admittedly it is a bit 
difficult to read the output for the first time, but scanning the diff
I was able to see hints of what you were saying.  I'll file off a bug
report to AdaCore