Expected exception is not thrown in Windows XP, should be a compiler bug?

Expected exception is not thrown in Windows XP, should be a compiler bug?

[ake.ragnar.dahlgren]

What follows are two code snippets that are nearly identical but completely different behavior during runtime.

Consider the following code:

with Ada.Text_IO;
with Ada.Strings.Fixed;
with GNATCOLL.SQL.Postgres;

procedure Main is
   Host_URL      : aliased constant String := "localhosta";
begin
   declare
      type Host_URL_Type is new String (1 .. 9);

      Target_Host_URL      : Host_URL_Type;
   begin
         Ada.Strings.Fixed.Move (Source  => Host_URL,
                                 Target  => String (Target_Host_URL));
   end;
exception
   when others =>
      Ada.Text_IO.Put_Line("Write some error message");
end Main;

When compiled under Windows XP, Gnatcoll release 1.5w is used and GNAT PRO is version .1.0w-20121028 based upon gcc version 4.7.3 one gets the following output:

C:\temp>main

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

C:\temp>





Now consider the following code:

with Ada.Text_IO;
with Ada.Strings.Fixed;
--with GNATCOLL.SQL.Postgres;

procedure Main is
   Host_URL      : aliased constant String := "localhosta";
begin
   declare
      type Host_URL_Type is new String (1 .. 9);

      Target_Host_URL      : Host_URL_Type;
   begin
         Ada.Strings.Fixed.Move (Source  => Host_URL,
                                 Target  => String (Target_Host_URL));
   end;
exception
   when others =>
      Ada.Text_IO.Put_Line("Write some error message");
end Main;

It has the expected output:

C:\temp>main
Write some error message

C:\temp>



The only difference between the two applications is whether the package GNATCOLL.SQL.Postgres is with:ed or not. It is not even used and therefore should not have any impact on the behavior of the application. I cannot detect this bug on my Mac OS X computer at home with GNAT Libre installed on it. Is there anybody else at comp.lang.ada that can detect this bug?

Best regards,
Åke Ragnar Dahlgren

Re: Expected exception is not thrown in Windows XP, should be a compiler bug?

[Niklas Holsti]

On 13-05-27 12:10 , ake.ragnar.dahlgren@gmail.com wrote:
> What follows are two code snippets that are nearly identical
> but completely different behavior during runtime.
> 
> Consider the following code:
> 
> with Ada.Text_IO;
> with Ada.Strings.Fixed;
> with GNATCOLL.SQL.Postgres;

   [snip]

> When compiled under Windows XP, Gnatcoll release 1.5w is
> used and GNAT PRO is version .1.0w-20121028 based upon gcc
> version 4.7.3 one gets the following output:
> 
> C:\temp>main
> 
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
>
> 
> Now consider the following code:
> 
> with Ada.Text_IO;
> with Ada.Strings.Fixed;
> --with GNATCOLL.SQL.Postgres;

   [snip]

> It has the expected output:
> 
> C:\temp>main
> Write some error message
> 
> The only difference between the two applications is whether
> the package GNATCOLL.SQL.Postgres is with:ed or not. It is not
> even used and therefore should not have any impact on the
> behavior of the application.

If you "with" GNATCOLL.SQL.Postgres, that package (and packages that it
depends on) are elaborated at run time, before your main procedure
starts executing its statements. I don't know what sort of elaboration
code those packages contain, but, in general, elaboration code can do
anything that ordinary code can do, including making calls to operating
system functions that may fail in some way, which perhaps causes the
error message that you quoted. The reason for such failures may be
something in the operating environment -- perhaps a missing environment
variable, or a faulty value in an environment variable -- and is not
*necessarily* a bug in the program or in the compiler.

I would look into GNATCOLL.SQL.Postgres, or into its documentation (if
any) to see if its elaboration code can cause the error, and under what
circumstances.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Expected exception is not thrown in Windows XP, should be a compiler bug?

[Jesper Quorning]

Den mandag den 27. maj 2013 12.10.16 UTC+2 skrev ake.ragna...@gmail.com:

> C:\temp>main
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

I have seen this message in CygWin bash. Check TMP or TEMP environment variables in bashrc.

Mvh
Jesper
 

Re: Expected exception is not thrown in Windows XP, should be a compiler bug?

[ake.ragnar.dahlgren]

Den måndagen den 27:e maj 2013 kl. 16:45:14 UTC+2 skrev Niklas Holsti:
> On 13-05-27 12:10 , ake.ragnar.dahlgren@gmail.com wrote: > What follows are two code snippets that are nearly identical > but completely different behavior during runtime. > > Consider the following code: > > with Ada.Text_IO; > with Ada.Strings.Fixed; > with GNATCOLL.SQL.Postgres; [snip] > When compiled under Windows XP, Gnatcoll release 1.5w is > used and GNAT PRO is version .1.0w-20121028 based upon gcc > version 4.7.3 one gets the following output: > > C:\temp>main > > This application has requested the Runtime to terminate it in an unusual way. > Please contact the application's support team for more information. > > > Now consider the following code: > > with Ada.Text_IO; > with Ada.Strings.Fixed; > --with GNATCOLL.SQL.Postgres; [snip] > It has the expected output: > > C:\temp>main > Write some error message > > The only difference between the two applications is whether > the package GNATCOLL.SQL.Postgres is with:ed or not. It is not > even used and therefore should not have any impact on the > behavior of the application. If you "with" GNATCOLL.SQL.Postgres, that package (and packages that it depends on) are elaborated at run time, before your main procedure starts executing its statements. I don't know what sort of elaboration code those packages contain, but, in general, elaboration code can do anything that ordinary code can do, including making calls to operating system functions that may fail in some way, which perhaps causes the error message that you quoted. The reason for such failures may be something in the operating environment -- perhaps a missing environment variable, or a faulty value in an environment variable -- and is not *necessarily* a bug in the program or in the compiler. I would look into GNATCOLL.SQL.Postgres, or into its documentation (if any) to see if its elaboration code can cause the error, and under what circumstances. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .

Thank you and Jesper for your thoughts.

I should further investigate the possibility of a missing environment variable, but if I add more logging to standard out it seems to me that the problem does not occur during elaboration time but during execution of the Ada.Strings.Fixed.Move command. Consider:

with Ada.Text_IO;
with Ada.Strings.Fixed;
with GNATCOLL.SQL.Postgres;

procedure Main is
   Host_URL      : aliased constant String := "localhosta";
begin
   declare
      type Host_URL_Type is new String (1 .. 9);

      Target_Host_URL      : Host_URL_Type;
   begin
      Ada.Text_IO.Put_Line ("Will execute Main method");
      Ada.Strings.Fixed.Move (Source  => Host_URL,
                              Target  => String (Target_Host_URL));
      Ada.Text_IO.Put_Line("Executed Main method");
   end;
exception
   when others =>
      Ada.Text_IO.Put_Line("Write some error message");
end Main;

It has the following output:

C:\temp>main
Will execute Main method

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

C:\temp>


Maybe the GNATCOLL.SQL.Postgres package creates a new task that executes some C-code which makes the whole application crash and it just happens to do so during the execution of the Ada.Strings.Fixed.Move command by the environment task?

Best regards,
Åke Ragnar Dahlgren

Re: Expected exception is not thrown in Windows XP, should be a compiler bug?

[Niklas Holsti]

On 13-05-28 12:17 , ake.ragnar.dahlgren@gmail.com wrote:
> Den måndagen den 27:e maj 2013 kl. 16:45:14 UTC+2 skrev Niklas Holsti:

   [ snip totally format-clobbered quote ]

> Thank you and Jesper for your thoughts.
> 
> I should further investigate the possibility of a
> missing environment variable, but if I add more logging to
> standard out it seems to me that the problem does not occur
> during elaboration time but during execution of the Ada.Strings.Fixed.Move
> command. Consider:
> 
> with Ada.Text_IO;
> with Ada.Strings.Fixed;
> with GNATCOLL.SQL.Postgres;
> 
> procedure Main is
>    Host_URL      : aliased constant String := "localhosta";
> begin
>    declare
>       type Host_URL_Type is new String (1 .. 9);
> 
>       Target_Host_URL      : Host_URL_Type;
>    begin
>       Ada.Text_IO.Put_Line ("Will execute Main method");
>       Ada.Strings.Fixed.Move (Source  => Host_URL,
>                               Target  => String (Target_Host_URL));

I don't know if this is related to the problem, but this call of Move
should propagate Length_Error, since the Target is only 9 characters
long but the Source is 10 characters (and the overflow character is not
a space).

Of course this Length_Error should be caught in your catch-all handler,
below:

>       Ada.Text_IO.Put_Line("Executed Main method");
>    end;
> exception
>    when others =>
>       Ada.Text_IO.Put_Line("Write some error message");
> end Main;
> 
> It has the following output:
> 
> C:\temp>main
> Will execute Main method
> 
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.

> Maybe the GNATCOLL.SQL.Postgres package creates a new task that executes
> some C-code which makes the whole application crash and it just happens
> to do so during the execution of the Ada.Strings.Fixed.Move command by
> the environment task?

... or during the exception-handling in the environment task. I think
that is possible .. in principle, but it seems a bit unlikely. So
perhaps there is a real bug somewhere.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .