Access check failed without using the word "access" in source

Access check failed without using the word "access" in source

[Natasha Kerensikova]

Hello,

running the code below after compiling it with GNAT GPL 2013, I get a
Constraint_Error because of an access check failure, even though the
source does not contain a single occurrence of the word "access".

However I might be doing something so wrong it escape compiler warnings,
so I'm submitting here before concluding about a compiler bug.
Do you see anything wrong with my code or is it supposed to run fine?

Below is the source, the compilation commands, and my first
pokings-in-the-dark about a probable cause.

Thanks in advance for your help.




$ cat >testcase.ada <<-EOF
package P is

   type I is limited interface;

end P;

with Ada.Finalization;

package P.C is

   type H is private;

   function Create (S : String) return H;

   function Process (Self : H) return I'Class;

   function Process (S : String) return I'Class;

private

   type H is null record;

   type Internal is new Ada.Finalization.Limited_Controlled and I
     with null record;

end P.C;

package body P.C is

   function Create (S : String) return H is
   begin
      return H'(null record);
   end Create;

   function Process (Self : H) return I'Class is
   begin
      return Internal'(Ada.Finalization.Limited_Controlled with null record);
   end Process;

   function Process (S : String) return I'Class is
   begin
      return Process (Create (S));
   end Process;

end P.C;

with Ada.Text_IO;

with P.C;

procedure Main is
begin
   Ada.Text_IO.Put_Line ("Begin");

   declare
      Object : P.I'Class := P.C.Process ("foo");
   begin
      null;
   end;

   Ada.Text_IO.Put_Line ("End");
end Main;
EOF

$ gnatchop testcase.ada
splitting testcase.ada into:
   p.ads
   p-c.ads
   p-c.adb
   main.adb
$ gnatmake main.adb
gcc -c main.adb
gcc -c p.ads
gcc -c p-c.adb
gnatbind -x main.ali
gnatlink main.ali
$ ./main
Begin

raised CONSTAINT_ERROR p-c.adb:16 access check failed
$ rm *.o *.ali
$ gnatmake -gnatD main.adb
gcc -c -gnatD main.adb
gcc -c -gnatD p.ads
gcc -c -gnatD p-c.adb
gnatbind -x main.ali
gnatlink main.ali
$ ./main
Begin

raised CONSTAINT_ERROR p-c.adb.dg:322 access check failed
$ nl -ba p-c.adb.bg | sed -n 319,332p
   319	         [constraint_error when
   320	           ada__tags__addr_ptr!(C85b) = null
   321	           "access check failed"]
   322	         [constraint_error when
   323	           ada__tags__type_specific_data_ptr!(ada__tags__addr_ptr!(C85b).all) =
   324	             null
   325	           "access check failed"]
   326	         [program_error when
   327	           ada__tags__type_specific_data_ptr!(ada__tags__addr_ptr!(C85b).all).all.
   328	             access_level > 0
   329	           "accessibility check failed"]
   330	         return R76b;
   331	      end R77b;
   332	   end p__c__process;

So from what I understand here, P.C.Process doesn't return a P.I'Class
object (as in the actual source) but rather an access (or a pointer, not
sure about the correct vocabulary at this level), which a reasonable
implementation.

The snipped quoted above looks like a "not null" check and an
accessibility check on the return value of the inner P.C.Process, before
returning it in the outer P.C.Process.

And indeed, the access returned by the inner P.C.Process is not null,
but the access/pointer to the accessibility level is.

At this point, I have no idea what further conclusions can be drawn from
here...

Re: Access check failed without using the word "access" in source

[Adam Beneschan]

On Thursday, August 22, 2013 7:26:36 AM UTC-7, Natasha Kerensikova wrote:

> So from what I understand here, P.C.Process doesn't return a P.I'Class
> object (as in the actual source) but rather an access (or a pointer, not
> sure about the correct vocabulary at this level), which a reasonable
> implementation.

Sure, it would be common for an implementation to return a pointer when the return type is something whose size isn't determinable beforehand (such as an unconstrained array or I'Class).  However, since implicit pointers like this aren't access objects (as defined by Ada), they shouldn't be causing Constraint_Errors.

It's definitely possible for an *accessibility* check to fail even when there are no access objects in the program (that can happen when a tagged type inside a function is derived from a type outside the function, and the function tries to return an object of the inside type, which fails because the outside world isn't allowed to see any objects of the inside type).  But accessibility check failures raise Program_Error.  It definitely looks like something is being checked for null.  So I'd say this is a definite compiler bug.

For what it's worth, I don't think you need the Create to reproduce the problem; if you remove it, and remove the Self parameter from one of the Process functions, it still fails.  But it doesn't fail if the main program calls that Process directly instead of the one with the String parameter.

                             -- Adam