Strange bug in GNAT

Strange bug in GNAT

[Natasha Kerensikova]

Hello,

I have encoutered a very strange bug in GNAT, and I can't understand how
anything can go wrong to produce such results. And I have not been able
to cut the project into a smallish reproducer. I would love to read your
insight in this.

I would also be interested in whether you can reproduce the problem on
some other platform or compiler version (I'm using GNAT-AUX 4.9.0 on
FreeBSD), but considering it depends on AWS and my personal helper
library, it might be too much to ask.

Fortunately the affected project is open source and published. Please
consider
https://github.com/faelys/simple-webapps/blob/f6b6db20aca49fce4b99c921f80492f47ae8f617/src/simple_webapps-upload_servers.adb#L157-L163

The general context is that the package implements a Dispatcher for AWS,
that starts with a `case` statement on the request, where a special
processing of POST request is performed, GET is processed outside of
the case, and all other methods are responded to with a 405 error.

It used to look like that:

         when others =>
            return AWS.Response.Acknowledge (AWS.Messages.S405);
      end case;

and everything worked fine.

Then I wanted to use templates for HTTP error pages, because my browsers
don't actually show my the HTTP response code, but rather whatever
contents are sent along. The line above sends an empty string, which
isn't terribly useful.

So I wrote a body-local function Error_Page that build the error page
according to the given template, with a hardcoded fallback when no
template file is provided. The quote above was changed to the following:

         when others =>
            return Error_Page
              (AWS.Messages.S405,
               Dispatcher.DB.Query.Data.Error_Template);
      end case;

GNAT refused to compile it, with surprising error messages: it
complained that two unrelated subprograms marked overriding were not
actually overriding (it turned out that they are *all* the overriding
subprograms written after the quote above).

I experimented with changing them from `overriding` to `not overriding`,
and GNAT complained that it's illegal because said subprograms are not
primitive.

How can changing from one of the version above into another can change
de primitiveness of a subprogram!?

Then I removed the overriding indicators entirely, and GNAT still
rejected the file, because a bunch of subprograms were defined without
prior declaration (actually that affected all subprograms after the
change above).

So I also removed the style warnings, and now the package did compile,
but then gnatlink failed with a bunch of missing symbols, corresponding
roughly to the subprograms mentioned in the style errors.

After a lot of experimentation, I found the following workaround, which
is committed:

         when others =>
            begin
               return Error_Page
                 (AWS.Messages.S405,
                  Dispatcher.DB.Query.Data.Error_Template);
            end;
      end case;

How can an anonymous block change anything?

I tried compiling with -gnatD flag, but I couldn't find anything
strange in the diff between with and without the extra begin/end, only a
few more labels and temporary types.

At this point, I'm completely lost on how to proceed. I would love to
report the bug, so that hopefully it might eventually be fixed, but
without a smallish reproducer I don't dare bothering AdaCore.


Now I'm wondering whether something weird might occur with the
expression `Dispatcher.DB.Query.Data`, since in the very same function I
have an uninvestigated GNAT bugbox triggered by

            elsif Dispatcher.DB.Query.Data.Debug_Activated
              and then AWS.Status.URI (Request) = "/dump-form"
            then

but not by

            elsif AWS.Status.URI (Request) = "/dump-form"
              and then Dispatcher.DB.Query.Data.Debug_Activated
            then

For the record, `Dispatcher` is the tagged object on which the function
is primitive, and it's a record with a `DB` component, `Query` is a
primitive function with returns an accessor record, of which `Data` is
the access discriminant, there is an implicit dereference, and
`Debug_Activated` and `Error_Template` are protected functions.


Thanks in advance for your insights,
Natasha

Re: Strange bug in GNAT

[Simon Wright]

Natasha Kerensikova <lithiumcat@instinctive.eu> writes:

> After a lot of experimentation, I found the following workaround, which
> is committed:
>
>          when others =>
>             begin
>                return Error_Page
>                  (AWS.Messages.S405,
>                   Dispatcher.DB.Query.Data.Error_Template);
>             end;
>       end case;
>
> How can an anonymous block change anything?
[...]
> At this point, I'm completely lost on how to proceed. I would love to
> report the bug, so that hopefully it might eventually be fixed, but
> without a smallish reproducer I don't dare bothering AdaCore.

Back when I was working on a supported project, I had a somewhat similar
problem with a deeply-nested loop; AdaCore suggested using an anonymous
block around some of the inner levels, which turned out to be a good
workround.

I suppose that the block resets some of the compiler internals, enough
to prevent the problem manifesting itself.

I don't think you should worry too much about the size of the
reproducer; if they're interested they'll look, if not, not. But it
might be best to supply all the source needed to compile the problematic
unit (in a zip archive, for example).

Is there any chance that you can reproduce the problem using GNAT GPL?
You stand a *much* better chance of getting the problem looked at if so.

Re: Strange bug in GNAT

[G.B.]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

On 02.07.14 22:12, Simon Wright wrote:
> Is there any chance that you can reproduce the problem using GNAT GPL?

It works with or without the anonymous block with GNAT GPL 2014
and AWS GPS 2014 on a Mac. I have had to tweak the make .gpr
a bit, to make it independent of the testing setup. The unit
"tests/minimal.adb" is like "tests/upload_server.adb" without
the non-debug branches.



[-- Attachment #2: simple-webapps.diff --]
[-- Type: text/plain, Size: 1169 bytes --]

diff --git a/src/simple_webapps-upload_servers.adb b/src/simple_webapps-upload_servers.adb
index 71c2892..c16fab3 100644
--- a/src/simple_webapps-upload_servers.adb
+++ b/src/simple_webapps-upload_servers.adb
@@ -155,11 +155,11 @@ package body Simple_Webapps.Upload_Servers is
             null;  --  processed below
 
          when others =>
-            begin  --  explicit block needed to work around a GNAT parsing bug
+--          begin  --  explicit block needed to work around a GNAT parsing bug
                return Error_Page
                  (AWS.Messages.S405,
                   Dispatcher.DB.Query.Data.Error_Template);
-            end;
+--          end;
       end case;
 
       declare
diff --git a/webapps.gpr b/webapps.gpr
index 53b2130..4ad6a93 100644
--- a/webapps.gpr
+++ b/webapps.gpr
@@ -15,10 +15,10 @@ project Webapps is
          Prefix := "coverage/";
    end case;
 
-   for Source_Dirs use ("src");
+   for Source_Dirs use ("src", "tests");
    for Object_Dir use Prefix & "obj";
    for Exec_Dir use Prefix & "bin";
-   for Main use ("upload_server.adb");
+   for Main use ("minimal.adb");
 
    case Mode is
       when "Release" =>

Re: Strange bug in GNAT

[Natasha Kerensikova]

Hello,

On 2014-07-03, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>> Is there any chance that you can reproduce the problem using GNAT GPL?
>
> It works with or without the anonymous block with GNAT GPL 2014
> and AWS GPS 2014 on a Mac. I have had to tweak the make .gpr
> a bit, to make it independent of the testing setup. The unit
> "tests/minimal.adb" is like "tests/upload_server.adb" without
> the non-debug branches.

I guess that means there is no point in reporting it to AdaCore, at best
it's a GNAT issue that hasn't made it to FSF branch, at worst it's a
FSF-only problem.

Thanks a lot for having gone through the trouble of testing my code.


Natasha

Re: Strange bug in GNAT

[Natasha Kerensikova]

On 2014-07-02, Simon Wright <simon@pushface.org> wrote:
> Is there any chance that you can reproduce the problem using GNAT GPL?
> You stand a *much* better chance of getting the problem looked at if so.

I don't really have an easy access to a platform where GNAT GPL is
available, so I was hoping somebody here would beat me to it -- and
indeed G.B. did.


Natasha