GNAT bug - still in 2010?

GNAT bug - still in 2010?

[Maciej Sobczak]

Consider:

with Ada.Unchecked_Deallocation;

procedure Test is

   package P is
      type My_Interface is limited interface;
      procedure Do_Something (X : in out My_Interface) is abstract;
   end P;

   protected type My_Protected is new P.My_Interface with
      overriding
      procedure Do_Something;
   end My_Protected;

   protected body My_Protected is
      overriding
      procedure Do_Something is
      begin
         null;
      end Do_Something;
   end My_Protected;

   type My_Protected_Ptr is access My_Protected;

   procedure Free is new Ada.Unchecked_Deallocation
     (Object => My_Protected, Name => My_Protected_Ptr);

   Ptr : My_Protected_Ptr;

begin
   --   here come dragons:
   --Free (Ptr);
   null;
end Test;


If the indicated line (call to Free) is uncommented, GNAT crashes in
flames (GNAT BUG DETECTED).

I was finally able to reduce this to a minimal example, which might be
a good candidate for bug report (one in the long series of bugs
related to interfaces), but before I submit it I would like to kindly
ask you to confirm if this is still the case with GNAT 2010.
Certainly the bug is in versions GPL 2009 (20090519) and in 4.4.0
20080314.

--
Maciej Sobczak * http://www.inspirel.com

Re: GNAT bug - still in 2010?

[Alexander S. Mentis]

Maciej Sobczak wrote:

> Consider:
> 
> with Ada.Unchecked_Deallocation;
> 
> procedure Test is
> 
>    package P is
>       type My_Interface is limited interface;
>       procedure Do_Something (X : in out My_Interface) is abstract;
>    end P;
> 
>    protected type My_Protected is new P.My_Interface with
>       overriding
>       procedure Do_Something;
>    end My_Protected;
> 
>    protected body My_Protected is
>       overriding
>       procedure Do_Something is
>       begin
>          null;
>       end Do_Something;
>    end My_Protected;
> 
>    type My_Protected_Ptr is access My_Protected;
> 
>    procedure Free is new Ada.Unchecked_Deallocation
>      (Object => My_Protected, Name => My_Protected_Ptr);
> 
>    Ptr : My_Protected_Ptr;
> 
> begin
>    --   here come dragons:
>    --Free (Ptr);
>    null;
> end Test;
> 
> 
> If the indicated line (call to Free) is uncommented, GNAT crashes in
> flames (GNAT BUG DETECTED).
> 
> I was finally able to reduce this to a minimal example, which might be
> a good candidate for bug report (one in the long series of bugs
> related to interfaces), but before I submit it I would like to kindly
> ask you to confirm if this is still the case with GNAT 2010.
> Certainly the bug is in versions GPL 2009 (20090519) and in 4.4.0
> 20080314.

Yes, under Windows it demonstrates the same behavior.

Re: GNAT bug - still in 2010?

[Maciej Sobczak]

On 27 Paź, 18:11, "Alexander S. Mentis" <f...@invalid.invalid> wrote:

> Yes, under Windows it demonstrates the same behavior.

Thank you. It is a real shame.

I thought that it might be possible to work around the problem with a
mix-in - that is, instead of deriving the protected type from
interface, move the interface down as a component of the protected
type. The additional type derived from the interface would take the
access discriminant pointing to the enclosing protected object and
delegate dispatching calls to the protected object.
Something like this:

   package P is
      type My_Interface is limited interface;
      procedure Do_Something (X : in out My_Interface) is abstract;
   end P;

   type My_Protected;
   type My_Interface_Mixin (Parent : access My_Protected) is
     new P.My_Interface with null record;

   --  the top-level protected type is no longer
   --  derived from My_Interface...:
   protected type My_Protected is
      procedure Do_Something;
   private
      --  ...and instead the derived type is now here,
      --  bound to the enclosing object:
      Mixin : My_Interface_Mixin (My_Protected'Access);
   end My_Protected;

   overriding
   procedure Do_Something (X : in out My_Interface_Mixin) is
   begin
      --  delegate to the enclosing protected object
      X.Parent.all.Do_Something;
   end Do_Something;

   protected body My_Protected is
      procedure Do_Something is
      begin
         null;
      end Do_Something;
   end My_Protected;


Guess what? The compiler crashes again. Does it deserve a distinct bug
report?

In any case, I would like to ask you whether the above approach makes
sense as a programming technique. It does not compile :-), but I would
like to know if from the idiomatic point of view it is constructed
properly.
What bothers me is whether it is possible to declare overriding
operation Do_Something for My_Interface_Mixin after the completion of
My_Protected - that is, isn't My_Interface_Mixin already frozen there?

(what a mess)

--
Maciej Sobczak * http://www.inspirel.com

Re: GNAT bug - still in 2010?

[Georg Bauhaus]

On 10/27/10 5:00 PM, Maciej Sobczak wrote:

> procedure Test is
> [...]
> end Test;
>
>
> If the indicated line (call to Free) is uncommented, GNAT crashes in
> flames (GNAT BUG DETECTED).
>
> I was finally able to reduce this to a minimal example, which might be
> a good candidate for bug report (one in the long series of bugs
> related to interfaces), but before I submit it I would like to kindly
> ask you to confirm if this is still the case with GNAT 2010.
> Certainly the bug is in versions GPL 2009 (20090519) and in 4.4.0
> 20080314.

On Mac OS X, running both GNAT 2010 and GNAT 2009, I get

$ gnatmake -gnatf -gnatv -gnat05 -gnatwa test.adb
gcc -c -gnatf -gnatv -gnat05 -gnatwa test.adb

GNAT GPL 2010 (20100603)
Copyright 1992-2010, Free Software Foundation, Inc.

Compiling: test.adb (source file time stamp: 2010-10-27 21:02:39)

     12.      procedure Do_Something;
                        |
         >>> warning: procedure "Do_Something" is not referenced

     32.    Free (Ptr);
            1     2
         >>> "" is undefined
         >>> expected private type "System.Tasking.Protected_Objects.Protection"
         >>> found type "System.Tasking.Protected_Objects.Entries.Protection_Entries"
         >>>   ==> in call to "Finalize_Protection" at s-taprob.ads:244

  35 lines: 4 errors, 1 warning
gnatmake: "test.adb" compilation error


$ gnatmake -gnatf -gnatwa -gnat05 -gnatv test.adb
gcc -c -gnatwa -gnat05 -gnatv test.adb

GNAT GPL 2009 (20090519)
etc., same  messages

Re: GNAT bug - still in 2010?

[Maciej Sobczak]

On 27 Paź, 23:09, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
wrote:

> $ gnatmake -gnatf -gnatwa -gnat05 -gnatv test.adb
> gcc -c -gnatwa -gnat05 -gnatv test.adb
>
> GNAT GPL 2009 (20090519)
> etc., same  messages

$ gnatmake -gnatf -gnatwa -gnat05 -gnatv test.adb
gcc -c -gnatf -gnatwa -gnat05 -gnatv test.adb

GNAT GPL 2009 (20090519)
Copyright 1992-2009, Free Software Foundation, Inc.
+===========================GNAT BUG
DETECTED==============================+
| GPL 2009 (20090519) (x86_64-apple-darwin9.6.0) Constraint_Error
erroneous memory access|


I also work on Mac and I have the same compiler version.
Looks like there are different "same" compiler versions...

--
Maciej Sobczak * http://www.inspirel.com

Re: GNAT bug - still in 2010?

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> On 27 Paź, 23:09, Georg Bauhaus <rm-host.bauh...@maps.futureapps.de>
> wrote:
>
>> $ gnatmake -gnatf -gnatwa -gnat05 -gnatv test.adb
>> gcc -c -gnatwa -gnat05 -gnatv test.adb
>>
>> GNAT GPL 2009 (20090519)
>> etc., same  messages
>
> $ gnatmake -gnatf -gnatwa -gnat05 -gnatv test.adb
> gcc -c -gnatf -gnatwa -gnat05 -gnatv test.adb
>
> GNAT GPL 2009 (20090519)
> Copyright 1992-2009, Free Software Foundation, Inc.
> +===========================GNAT BUG
> DETECTED==============================+
> | GPL 2009 (20090519) (x86_64-apple-darwin9.6.0) Constraint_Error
> erroneous memory access|
>
>
> I also work on Mac and I have the same compiler version.
> Looks like there are different "same" compiler versions...

This is a bit worrying. I suspect you may be using one of the compilers
that I built for Snow Leopard? 

Here, the AdaCore 2009 & 2010 compilers (which were built with
--enable-checking=release) behave as Georg reports, whereas my builds,
including GCC 4.5.0 (without --enable-checking=release) behave as you
report.

I don't think

    32.    Free (Ptr);
           1     2
        >>> "" is undefined
        >>> expected private type "System.Tasking.Protected_Objects.Protection"
        >>> found type "System.Tasking.Protected_Objects.Entries.Protection_Entries"
        >>>   ==> in call to "Finalize_Protection" at s-taprob.ads:244

is a sensible set of error messages; the compiler is clearly confused
and the bug box is arguably a better outcome!

Re: GNAT bug - still in 2010?

[Timo Warns]

It also crashes on Linux:

% gnatmake -gnatf -gnatv -gnat05 -gnatwa test.adb
gcc -c -gnatf -gnatv -gnat05 -gnatwa test.adb

GNAT GPL 2010 (20100603)
Copyright 1992-2010, Free Software Foundation, Inc.
+===========================GNAT BUG DETECTED==============================+
| GPL 2010 (20100603) (x86_64-pc-linux-gnu) Storage_Error stack overflow (or erroneous memory access)|
| Error detected at test.adb:32:4                                          |
| Please submit a bug report by email to report@adacore.com.               |
| GAP members can alternatively use GNAT Tracker:                          |
| http://www.adacore.com/ section 'send a report'.                         |
| See gnatinfo.txt for full info on procedure for submitting bugs.         |
| Use a subject line meaningful to you and us to track the bug.            |
| Include the entire contents of this bug box in the report.               |
| Include the exact gcc or gnatmake command that you entered.              |
| Also include sources listed below in gnatchop format                     |
| (concatenated together with no headers between files).                   |
| Use plain ASCII or MIME attachment.                                      |
+==========================================================================+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

test.adb


Compiling: test.adb (source file time stamp: 2010-10-28 07:14:41)
 35 lines: No errors
compilation abandoned
gnatmake: "test.adb" compilation error

Re: GNAT bug - still in 2010?

[Maciej Sobczak]

On 27 Paź, 23:56, Simon Wright <si...@pushface.org> wrote:

> > I also work on Mac and I have the same compiler version.
> > Looks like there are different "same" compiler versions...
>
> This is a bit worrying. I suspect you may be using one of the compilers
> that I built for Snow Leopard?

No, this one I got from the Libre site, from AdaCore. I don't even
have SL, so for sure it is not yours. :-) I agree that it's a mess and
certainly it does not help to make Ada any more popular.

The other (older) compiler that I have comes from macada.org, but it
also crashes.

Interestingly, the only reason I use two different compilers is that
the newer one does not integrate with C++ (we have discussed it on
this group already).

But now I've hit a wall that is too high for all existing compilers.
Not good.

--
Maciej Sobczak * http://www.inspirel.com

Re: GNAT bug - still in 2010?

[Maciej Sobczak]

On 27 Paź, 21:43, Maciej Sobczak <see.my.homep...@gmail.com> wrote:

> I thought that it might be possible to work around the problem with a
> mix-in - that is, instead of deriving the protected type from
> interface, move the interface down as a component of the protected
> type.

I will answer myself.
Yes, it is possible and this is what I did.

The only problems were:

1. I have immediately run into another compiler bug due to the fact
that the name of the protected type cannot be used with 'Access, like
here:

>    protected type My_Protected is
>       procedure Do_Something;
>    private
>       Mixin : My_Interface_Mixin (My_Protected'Access);  --  bang!
>    end My_Protected;

This bug seems to be already fixed in newer compilers, so I will not
report it.

2. I have defined the protected type and the mixin in two separate
packages. This required "limited with" for the package where the
protected type was defined, which does not work, as the compiler does
not see the protected type:

--  a.ads
package A is
   protected type PT is
   end PT;
end A;

--  b.ads
limited with A;
package B is
   type PT_Ptr is access PT;   -- "PT" is undefined
end B;

This compiler bug also seems to be fixed in newer versions, so I will
not report it.

I have solved both problems by passing System.Address around to
completely hide dependencies between packages and doing conversions to
recover the original type. It is a hack from hell, but until proper
compilers will become more widely used, I keep it as a valid solution.
Of course, I will welcome all other suggestions.

--
Maciej Sobczak * http://www.inspirel.com

Re: GNAT bug - still in 2010?

[Maciej Sobczak]

On 31 Paź, 22:24, Maciej Sobczak <see.my.homep...@gmail.com> wrote:

> --  a.ads
> package A is
>    protected type PT is
>    end PT;
> end A;
>
> --  b.ads
> limited with A;
> package B is
>    type PT_Ptr is access PT;   -- "PT" is undefined

Sorry for the typo, should be of course A.PT and then the compiler
says:

"PT" not declared in "A"

Non-protected types don't have this problem. As already said, this was
fixed in recent versions of GNAT.

--
Maciej Sobczak * http://www.inspirel.com