Compiler Bug or what I'm doing wrong?

Compiler Bug or what I'm doing wrong?

[M E Leypold]

Hi all,

the following happens with GNAT 3.15p on Debian. My impression is,
that finalization during reading with the compiler generated
'Read-Attribute is not handled right in variant records, but I might
be wrong. Let me first expose the problem and my sample code.

I have the following Program (explanations below):


    with Sf.Cases;
    use  Sf.Cases;

    with Sf.Fieldtypes;
    use  Sf.Fieldtypes;

    with Ada.Streams.Stream_IO;
    use  Ada.Streams.Stream_IO;


    procedure Demo.Bug3 is

       procedure Write_Record
       is
         R : Fall_Datensatz;

         F : File_Type;
         S : Stream_Access;
       begin
          Create( F , Name => "tmp-bug3" );
          S := Stream(F);
          Set_Zugang(R, SelbstMelderIn);          -- [**]
          -- Fall_Datensatz'Output(S,R); -- [2a]
          Fall_Datensatz'Write(S,R);     -- [1a]
          Close(F);
       end;

       Function Get_Record return Fall_Datensatz
       is
          R: Fall_Datensatz;
          F : File_Type;
          S : Stream_Access;
       begin
          Open( F , Mode => In_File, Name => "tmp-bug3" );
          S := Stream(F);

          -- R := Fall_Datensatz'Input(S); -- [2b]
          Fall_Datensatz'Read(S,R);        -- [1b]
          Close( F );
          return R;
       end;

       R : Fall_Datensatz;

    begin
       Write_Record;
       R := Get_Record;
    end;


It instantiated a record with default initialization, changes a
discriminant in a which controls a variant part in the record (at [**]
Set_Zugang will be explained later), and then stores the record in a
file. When rereading the file (Get_Record), I get the following
exception:


   "raised PROGRAM_ERROR : demo-bug3.adb:38 finalize raised exception"

Running it under debugger control I get 

   (gdb) exec-file demo-bug3
   (gdb) run
   Starting program: /home/mel/cvswork/statfix/src2/demo-bug3

   Program received signal SIGSEGV, Segmentation fault.
   0x4098d354 in mallopt () from /lib/libc.so.6
   (gdb)

   (gdb) bt 5
   #0  0x4098d354 in mallopt () from /lib/libc.so.6
   #1  0x4098c15f in free () from /lib/libc.so.6
   #2  0x408f4e84 in __gnat_free () from /usr/lib/libgnat-3.15p.so.1
   #3  0x4082ac79 in ada__strings__unbounded__finalize__2 ()
      from /usr/lib/libgnat-3.15p.so.1
   #4  0x080c9fe5 in <demo__bug3__get_record___read654___read1116___read1147> (
       s=0x80e2e00, v=@0xbfffc39c, <sF>=0) at demo-bug3.adb:38
   (More stack frames follow...)
   (gdb)

which makes me suspect that a finalizer is run on non-appropriate data
(i.e. on the wrong part of a variant). I'll attach more stack traces
below, but first let me explain the data structure Fall_Datensatz
(which is defined in SF.Cases). I'm showing only the parts that are
actually touched by the program:


   type PA_Kontakt_Ergebnis ( Erfolg : Di_State := Keine_Angabe ) is record

      case Erfolg is
         when Ja     => Kontakt_Ergebnis : Auswahl_Kontakt_Ergebnis := Keine_Angabe;         
         when others => null;
      end case;
   end record;


   type PA_Kontakt_Verlauf
     ( Kontakt_Methode : Auswahl_Kontakt_Methode := Keine_Angabe )
   is record
      case Kontakt_Methode is
         when Keine_Angabe => null;
         when Keinen       => null;
         when Others       => Ergebnis : PA_Kontakt_Ergebnis;
      end case;
   end record;


   type Zugangs_Daten( KlientIn_Zugang : Auswahl_KlientIn_Zugang := Keine_Angabe ) is record

      case KlientIn_Zugang is

         when  Proaktiver_Kontakt  =>

            Kontakt_Vermittlung : Angabe_Kontakt_Vermittlung ;
            PA_Kontakt          : PA_Kontakt_Verlauf         ;

         when      SelbstmelderIn  =>

            KlientIn_Aufmerksamkeit : Angabe_Klientin_Aufmerksamkeit;

         when              others  =>  null;
      end case;
   end record;




   type Fall_Datensatz
     ( KJB_Verf�gbar : Boolean := True ; Notizen_Verf�gbar : Boolean := True )
   is record

      Aktenzeichen  : Fall_Aktenzeichen;
      Tat           : Fall_Merkmale     (Notizen_Verf�gbar);

      Opfer         : Personen_Merkmale (Notizen_Verf�gbar);
      T�ter         : Personen_Merkmale (Notizen_Verf�gbar);

      Zugang        : Zugangs_Daten;
      Polizei       : Angaben_Polizei_Einsatz;

      Beratung      : Beratungsverlauf  (Notizen_Verf�gbar);

      Kinder        : Kinder_Daten; -- (KJB_Verf�gbar, Notizen_Verf�gbar);

      case KJB_Verf�gbar is
         when  True   => null; -- KJB : ...
         when  False  => null;
      end case;
   end record;


The Unbounded Strings are hidden in Angabe_Kontakt_Vermittlung and
Angabe_Klientin_Aufmerksamkeit which are actually Types defined via a
generic package as an enumeration type with an optional comment (only
to be given in some cases):


   type Data is record
      Choice  : Choice_Type      := Choice_Type'First;
      Comment : Unbounded_String := Null_Unbounded_String;
   end record;


(I'll give the complete interface below, but this post becomes pretty
longish, so I'll restrict myself to what I consider the relevant parts).

The procedure Set_Zugang modifies the diosriminant of Zugangs_Daten in
the following way:


   procedure Set_Zugang ( D :  in out Zugangs_Daten ; Z : Auswahl_KlientIn_Zugang )
   is begin

      if Z /= D.KlientIn_Zugang then

         case Z is

            when Selbstmelderin      =>
               declare New_D : Zugangs_Daten(Selbstmelderin);
               begin
                  D := New_D ;
               end;

            when Proaktiver_Kontakt  =>
               declare New_D : Zugangs_Daten(Proaktiver_Kontakt);
               begin   D := New_D ; end;

            when Keine_Angabe        => D := (KlientIn_Zugang => Keine_Angabe ) ;
         end case;
      end if;
   end;


   procedure Set_Zugang ( DS :  in out Fall_Datensatz ; Z : Auswahl_KlientIn_Zugang) is begin

      Set_Zugang( DS.Zugang, Z );
   end;

(The idea is to have the initialisation defaults if and only if the
discrimant is changed).

If  (in gdb) I step up some stackframes and print the record R in
Get_Record I get the following


  (...)  zugang => (klientin_zugang => selbstmelderin,
         klientin_aufmerksamkeit => ( choice => keine_angabe, comment
         => (prev => 0x0, next => 0x0, reference => Cannot access
         memory at address 0x7a9f08

This is also what led me to the impression that first the discriminant
is overwritten and the the finalizer(s) for the new variant part
("when SelbstMelderIn") are run (on random bit patterns) instead of
the finalizers for the default variant part ("when Keine_Angabe
..."). 

(Actually I'd have expected in the case of discriminant records that
the whole thingy works like this: Run all finalizers in variant parts
if any, only then read the discriminant, run the initializers in the
new variant parts, then read the rest of the record).

After having a look into Barnes "Programming in Ada 95" again, I
thought, that perhaps I should use 'Input and 'Output instead of 'Read
an 'Write. This fixed the problem in the case above (options [2a] and
[2b]), but unfortunately failed to fix the the problem in the larger
program from which these fragments come.

Of course the bug is a Heisenbug so small changes in Fall_Datensatz or
the order of code execuation in the larger program make it disappear
which made it difficult in the first place to construct a relatively
small example w/o GUI which succeeds in reproducing the bug. 

Therefore I think (but again I'm not sure) that the fact that the bug
goes away with 'Input and Output instead of 'Read/'Write is just part
of it's elusive character not evidence of a fix. Also, since records
with default discriminants are definite I think 'Read and 'Write
should be OK for IO. Am I not right?

I've googled a bit, but didn't find anything on that, eehm,
"effect". But maybe I didn't use the right keywords. 

Is this a known bug with GNAT 3.15p or am I doing anything wrong?

Your help/input (also suggestions for workaround or confirmation that
this indeed a GNAT bug) would be greatly appreciated.

(Ludovico: I'll file an entry into Debian bug tracking soon. Just
looking for confirmation here first).

Regards -- Markus



ATTACHEMENTS: Backtraces and more code
--------------------------------------

  Sf.Single-Choices (Unit interface from which the types Angabe_* are instantiated) 
  ------------------
  
     with Ada.Strings.Unbounded;
     use  Ada.Strings.Unbounded;

     generic

        type Choice_Type   is (<>);
        type Choice_List   is array (Integer range <>) of Choice_Type;

        Allow_Comment_List : Choice_List;

     package Sf.Single_Choice is

        type Data is private;

        procedure Set( D : in out Data ; C : Choice_Type );
        function  Get( D : Data ) return Choice_Type;
        function  ID ( D : Data ) return Integer;

        function  Get_Comment( D : Data ) return String;
        procedure Set_Comment( D : in out Data; S : String );

        procedure Set_From_Integer( D : in out Data ; I : Integer );

        procedure Set( D : in out Data ; I : Integer ) renames Set_From_Integer;

        procedure Reset ( D : in out Data );

     private

        type Flags is array (Choice_Type) of Boolean;

        function Get_Comment_Allowed_Vector return Flags;

        Comment_Allowed : constant Flags := Get_Comment_Allowed_Vector;

        type Data is record
           Choice  : Choice_Type      := Choice_Type'First;
           Comment : Unbounded_String := Null_Unbounded_String;
        end record;
     end;



  complete backtrace
  ------------------

  #0  0x4098d354 in mallopt () from /lib/libc.so.6
  #1  0x4098c15f in free () from /lib/libc.so.6
  #2  0x408f4e84 in __gnat_free () from /usr/lib/libgnat-3.15p.so.1
  #3  0x4082ac79 in ada__strings__unbounded__finalize__2 ()
     from /usr/lib/libgnat-3.15p.so.1
  #4  0x080c9fe5 in <demo__bug3__get_record___read654___read1116___read1147> (
      s=0x80e2e00, v=@0xbfffc39c, <sF>=0) at demo-bug3.adb:38
  #5  0x080ca136 in <demo__bug3__get_record___read654___read1116> (s=0x80e2e00,
      v=@0xbfffc384, <sF>=0, <vF>=false) at demo-bug3.adb:38
  #6  0x080d5997 in <demo__bug3__get_record___read654> (s=0x80e2e00, v=@0xbfffc108,
      <sF>=0, <vF>=false) at demo-bug3.adb:38
  #7  0x080d869f in demo.bug3.get_record () at demo-bug3.adb:38
  #8  0x080dd625 in demo.bug3 () at demo-bug3.adb:48
  #9  0x080640dd in main (argc=1, argv=(system.address) 0xbffff8a4,
      envp=(system.address) 0xbffff8ac) at b~demo-bug3.adb:244
  #10 0x40930e36 in __libc_start_main () from /lib/libc.so.6


  more information
  ----------------

  I've generated a core and also can reproduce the SIGSEGV in this
  configuration 100% of the time. Don't hesitate to ask for more
  debugger output or more code.

Re: Compiler Bug or what I'm doing wrong?

[Ludovic Brenta]

M E Leypold writes :
>   I've generated a core and also can reproduce the SIGSEGV in this
>   configuration 100% of the time. Don't hesitate to ask for more
>   debugger output or more code.

I'd ask for *less* code :-)

It would be nice if you could write a minimal test case that reproduces
the problem. Yes, it takes time. I cannot do that for you, for various
reasons. Please have a look at Debian's bug tracking system (package
gnat) or GCC's bugzilla for examples of good test cases.

-- 
Ludovic Brenta.

Re: Compiler Bug or what I'm doing wrong?

[M E Leypold]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> writes:

> M E Leypold writes :
> >   I've generated a core and also can reproduce the SIGSEGV in this
> >   configuration 100% of the time. Don't hesitate to ask for more
> >   debugger output or more code.
> 
> I'd ask for *less* code :-)
> 
> It would be nice if you could write a minimal test case that reproduces
> the problem. Yes, it takes time. I cannot do that for you, for various

I've already done that (it took me 10 hours so far to isolate the
problem from a larger program): The original program was much
larger. I'll be trying to even strip the example furter, but the
problem with the bug seems to be that it's a Heisenbug which vanishes
when you delete some fields in the datastructure, then turns up again
if you delete more fields and so on. The malloc() implementation of
libc which the GNAt runtime uses is unchecked so obviously one gets
sometimes away when freeing unvalid pointers and (as we know from C
programming).

Whatever: I'll try to produce an even smaller test case.

> reasons. Please have a look at Debian's bug tracking system (package
> gnat) or GCC's bugzilla for examples of good test cases.

Yes, I know what a good test case is and I know the debian bug
tracking system. You might consider my post to c.l.a. as a kind of
preliminary report: Basically I wanted to be sure that I haven't
overlooked anything glaringly obvious.

Regards -- Markus

Re: Compiler Bug or what I'm doing wrong?

[Alex R. Mosteo]

M E Leypold wrote:

> 
> "Ludovic Brenta" <ludovic@ludovic-brenta.org> writes:
> 
>> M E Leypold writes :
>> >   I've generated a core and also can reproduce the SIGSEGV in this
>> >   configuration 100% of the time. Don't hesitate to ask for more
>> >   debugger output or more code.
>> 
>> I'd ask for *less* code :-)
>> 
>> It would be nice if you could write a minimal test case that reproduces
>> the problem. Yes, it takes time. I cannot do that for you, for various
> 
> I've already done that (it took me 10 hours so far to isolate the
> problem from a larger program): The original program was much
> larger. I'll be trying to even strip the example furter, but the
> problem with the bug seems to be that it's a Heisenbug which vanishes
> when you delete some fields in the datastructure, then turns up again
> if you delete more fields and so on. The malloc() implementation of
> libc which the GNAt runtime uses is unchecked so obviously one gets
> sometimes away when freeing unvalid pointers and (as we know from C
> programming).

Indeed, for me the most frustrating part of bug reporting is obtaining a
sufficiently small test case. I usually hit bugs in a large project I'm
involved. Once you start to chop off, you know that the bug will disappear
along the way. When you're not even sure if you're the culprit and not the
compiler, the frustration is even bigger.

I'm now, for example, facing a spurious exception case when switching from
GNAT GPL'05 to GPL'06, only when certain compiler switches are used. I have
already found a workaround, and I even know that the problem is related
with interfaces, but I fear that the effort to isolate it will be a waste
of time. So the temptation to move on is big...

This post is really just to show my "condolences" and support. Best luck,

A. Mosteo.

Re: Compiler Bug or what I'm doing wrong?

[M E Leypold]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> I'm now, for example, facing a spurious exception case when switching from
> GNAT GPL'05 to GPL'06, only when certain compiler switches are used. I have

Have you tried to run that with a debugger? In my case I had
exceptions first and only when running that with the debugger, I found
that it was a SIGSEGV which got translated into a PROGRAM_ERROR by the
signal handler and the run time since this happened in a finalizer.

> already found a workaround, and I even know that the problem is related
> with interfaces, but I fear that the effort to isolate it will be a waste
> of time. So the temptation to move on is big...

In my case: I think I have found a workaround (if my guess on the
nature of the error is correct) and I'll post it here as a reference
for the next users if it actually works.

In my opinion, documentation of "known bugs" and "proved workarounds"
are almost as valuable as fixes. At least they'll spare other users
the time (a) to form suspicions themselves and (b) to think about
workarounds themselves.

It's a pity that GNAT (at least 3.15p? I'm repeating myself ...),
doesn't have some kind of community support side where things as these
could be collected. Or is there such a site?

For now I'm "misusing" c.l.a. for that but I wonder wether that was
right.

> This post is really just to show my "condolences" and support. Best luck,

Hey, thanks :-)). And good luck with your problem too.

Regards -- Markus

Re: Compiler Bug or what I'm doing wrong?

[James Dennett]

Alex R. Mosteo wrote:
> M E Leypold wrote:
> 
>> "Ludovic Brenta" <ludovic@ludovic-brenta.org> writes:
>>
>>> M E Leypold writes :
>>>>   I've generated a core and also can reproduce the SIGSEGV in this
>>>>   configuration 100% of the time. Don't hesitate to ask for more
>>>>   debugger output or more code.
>>> I'd ask for *less* code :-)
>>>
>>> It would be nice if you could write a minimal test case that reproduces
>>> the problem. Yes, it takes time. I cannot do that for you, for various
>> I've already done that (it took me 10 hours so far to isolate the
>> problem from a larger program): The original program was much
>> larger. I'll be trying to even strip the example furter, but the
>> problem with the bug seems to be that it's a Heisenbug which vanishes
>> when you delete some fields in the datastructure, then turns up again
>> if you delete more fields and so on. The malloc() implementation of
>> libc which the GNAt runtime uses is unchecked so obviously one gets
>> sometimes away when freeing unvalid pointers and (as we know from C
>> programming).
> 
> Indeed, for me the most frustrating part of bug reporting is obtaining a
> sufficiently small test case. I usually hit bugs in a large project I'm
> involved. Once you start to chop off, you know that the bug will disappear
> along the way. When you're not even sure if you're the culprit and not the
> compiler, the frustration is even bigger.

The "delta" tool can largely automate the task of reducing
a test case to something closer to minimal, though some
manual intervention helps:

http://gcc.gnu.org/wiki/A%20guide%20to%20testcase%20reduction

I've used it only a couple of times, but it saved me a *lot*
of effort.  (On the other hand, it might need tweaking to
support Ada; I don't know, I used it on C++ code.)

-- James

Re: Compiler Bug or what I'm doing wrong?

[Duncan Sands]

> M E Leypold writes :
>   I've generated a core and also can reproduce the SIGSEGV in this
>   configuration 100% of the time. Don't hesitate to ask for more
>   debugger output or more code.

This looks to be the same bug that we ran into with GNAT 3.15p some
time ago; it has long since been fixed, so I suggest you try a more
recent version of the compiler.

Best wishes,

Duncan.

Re: Compiler Bug or what I'm doing wrong?

[M E Leypold]

Duncan Sands <baldrick@free.fr> writes:

> > M E Leypold writes :
> >   I've generated a core and also can reproduce the SIGSEGV in this
> >   configuration 100% of the time. Don't hesitate to ask for more
> >   debugger output or more code.
> 

> This looks to be the same bug that we ran into with GNAT 3.15p some
> time ago;

Is there a report on that somewhere? Did you have a workaround?


> it has long since been fixed, so I suggest you try a more

Ah. "long since". Gnat 3.15p is now just 20 months old. 


> recent version of the compiler.


There is a number of reasons to stay with 3.15p yet. 

 - There is AFAIK no packaged version of a (free as in GMGPL) post
   3.15p Gnat fpr Windows.

 - Debian has 3.15p and will only switch to Gnat/Gcc in some months.

 - Changing now would mean, I have to build the compiler / toolchain
   myself (and that on both platforems) and if things get bad, also a
   number of libraries. Since experience is, that Gnat never builds
   out of the box I'd rather forfeit the experience for the time being
   -- not because I couldn't, but because it would eat up valuable
   time, probably much more than I have put into debugging and will
   have to put into writing a workaround.


Regards -- Markus

Re: Compiler Bug or what I'm doing wrong?

[Pascal Obry]

M E Leypold a �crit :

> Ah. "long since". Gnat 3.15p is now just 20 months old. 

Hum! No it was out on nov 18th 2002 so it is almost 4 years old.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Compiler Bug or what I'm doing wrong?

[Dmitry A. Kazakov]

On 22 Jun 2006 18:53:18 +0200, M E Leypold wrote:

> There is a number of reasons to stay with 3.15p yet. 
> 
>  - There is AFAIK no packaged version of a (free as in GMGPL) post
>    3.15p Gnat fpr Windows.
> 
>  - Debian has 3.15p and will only switch to Gnat/Gcc in some months.
> 
>  - Changing now would mean, I have to build the compiler / toolchain
>    myself (and that on both platforems) and if things get bad, also a
>    number of libraries. Since experience is, that Gnat never builds
>    out of the box I'd rather forfeit the experience for the time being
>    -- not because I couldn't, but because it would eat up valuable
>    time, probably much more than I have put into debugging and will
>    have to put into writing a workaround.

+ GPL editions compilers still look more buggy than 3.15p. GPL 2005 is
definitely worse. As for GPL 2006, I've tried it shortly today, it promptly
has shown the infamous GNAT bug-report shield...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Compiler Bug or what I'm doing wrong?

[Simon Wright]

M E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> It's a pity that GNAT (at least 3.15p? I'm repeating myself ...),
> doesn't have some kind of community support side where things as
> these could be collected. Or is there such a site?

What about the GNU Ada wiki at Sourceforge? http://gnuada.sourceforge.net/

Re: Compiler Bug or what I'm doing wrong?

[Jeffrey R. Carter]

On 22 Jun 2006 18:53:18 +0200, M E Leypold wrote:
> 
>  - There is AFAIK no packaged version of a (free as in GMGPL) post
>    3.15p Gnat fpr Windows.

What do you mean by "packaged"? There's the MinGW version of gcc 3.4.2 
including GNAT.

-- 
Jeff Carter
"Blessed are they who convert their neighbors'
oxen, for they shall inhibit their girth."
Monty Python's Life of Brian
83

Re: Compiler Bug or what I'm doing wrong?

[Ludovic Brenta]

M E Leypold writes:
> In my opinion, documentation of "known bugs" and "proved workarounds"
> are almost as valuable as fixes. At least they'll spare other users
> the time (a) to form suspicions themselves and (b) to think about
> workarounds themselves.
>
> It's a pity that GNAT (at least 3.15p? I'm repeating myself ...),
> doesn't have some kind of community support side where things as these
> could be collected. Or is there such a site?
>
> For now I'm "misusing" c.l.a. for that but I wonder wether that was
> right.

Use the Debian bug tracking system, it is public for precisely that
reason, even for people who do not use Debian.

-- 
Ludovic Brenta.

Re: Compiler Bug or what I'm doing wrong?

[M E Leypold]

Pascal Obry <pascal@obry.net> writes:

> M E Leypold a �crit :
> 
> > Ah. "long since". Gnat 3.15p is now just 20 months old. 
> 
> Hum! No it was out on nov 18th 2002 so it is almost 4 years old.

Ouch. I stand corrected.

I looked at the time stamps of files in a mirror (since the nyu server
is not carrying the files any more). Furthermore I was mislead by the
fact that debian/woody only had 3.14p, so the time stamps seemed
reasonable. Of course they weren't. My mistake.

But my other arguments still stand: 3.15p is not gone and should not
be considered so as long as major distributions have not upgraded
(yet) and as long as there is not a newer pre-packaged compiler for
windows.

Regards -- Markus

A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

Dear All,

I'm attaching a smaller (and now self contained test case!) for the
SIGSEGV whil reading/writing varaint records which I wrote about
earlier.

Some data:

 1. Gnat 3.15p on Debian Sarge.
 2. Running the attached program wil result in a SIGSEGV in a finalizer.

I'm also attaching a short backtrace.

Regards -- Markus


---


     with Ada.Streams.Stream_IO; use  Ada.Streams.Stream_IO;
     with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;

     procedure Demo.Bug3 is

        type Customer_Description( Is_Company : Boolean := True ) is record

           case Is_Company Is

              when  True   =>

                 Foo                 : Integer := 0;       -- remove these and the
                 Bar                 : Integer := 0;       -- SIGSEGV goes away
                 Company_Name        : Unbounded_String ;

              when  False  =>

                 Persons_Name        : Unbounded_String;

              when   others  =>  null;
           end case;
        end record;


        procedure Set_Zugang ( D :  in out Customer_Description ; Z : Boolean ) is begin

           if Z /= D.Is_Company then

              case Z is

                 when True      =>
                    declare New_D : Customer_Description(True);
                    begin
                       D := New_D ;
                    end;

                 when False  =>
                    declare New_D : Customer_Description(False);
                    begin   D := New_D ; end;

              end case;
           end if;
        end;


        procedure Write_Record
        is
          F : File_Type;
          S : Stream_Access;
          R : Customer_Description;
        begin
           Create( F , Name => "tmp-bug3" );
           S := Stream(F);
           Set_Zugang(R, False);                   -- remove this and the SIGSEGV goes away

           for I in 1 .. 400 loop
              Customer_Description'Write(S,R);     -- [1a]
           end loop;

           Close(F);
        end;


        procedure Get_Record
        is
           F : File_Type;
           S : Stream_Access;
        begin

           Open( F , Mode => In_File, Name => "tmp-bug3" );
           S := Stream(F);

           for I in 1 .. 400 loop
              declare R : Customer_Description;
              begin
                 Customer_Description'Read(S,R);        -- [1b]
              end;
           end loop;

           Close( F );
        end;

        R : Customer_Description;

     begin
        Write_Record;
        Get_Record;
     end;


---


Program received signal SIGSEGV, Segmentation fault.
0x408d1d41 in system__finalization_implementation__finalize_list ()
   from /usr/lib/libgnat-3.15p.so.1
#0  0x408d1d41 in system__finalization_implementation__finalize_list ()
   from /usr/lib/libgnat-3.15p.so.1
#1  0x408d1bdc in system__finalization_implementation__finalize ()
   from /usr/lib/libgnat-3.15p.so.1
#2  0x408d1d47 in system__finalization_implementation__finalize_list ()
   from /usr/lib/libgnat-3.15p.so.1
#3  0x0804cef9 in demo__bug3__get_record__B_4___clean.21 ()
#4  0x0804dec7 in demo.bug3.get_record () at demo-bug3.adb:77
#5  0x0804e203 in demo.bug3 () at demo-bug3.adb:88
#6  0x0804b4ad in main (argc=1, argv=(system.address) 0xbffff8a4,
    envp=(system.address) 0xbffff8ac) at b~demo-bug3.adb:180
#7  0x40930e36 in __libc_start_main () from /lib/libc.so.6

Re: Compiler Bug or what I'm doing wrong?

[M E Leypold]

Dear All,

I'd like to augment by recent post with following statements and
requests in case that got lost in the overwhelming amount of details:

 - This was no attempt ro actually "report a bug" to c.l.a. but rather
 
 - a request wether I have missed some glaring error of my own or
 
 - wether anybody has seen/documented something like this before.


My apologies that I'm still using Gnat 3.15p :-). I'm not asking you
to fix my problem (which is after all partly rooted in my stubborn
refusal to consider a newer compiler version just now), but only want
to tap your memory.

A shorter test case has been posted.

Regards (and thanks for all the help so far) -- Markus

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

M E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de> writes:

> Dear All,
> 
> I'm attaching a smaller (and now self contained test case!) for the
> SIGSEGV whil reading/writing varaint records which I wrote about
> earlier.


Forgot to add (especially at Ludovico: A bug report to the debian
tracking system will be posted).

Regards -- Markus

And a Workaround: Was: A smaller test case / Compiler Bug

[M E Leypold]

Dear All,

Here is a workaround for the problem with reading/writing variant
records with finalizers which I reported before.

One should override the read/write attributes of the record in
question. The substituted procedures should 

  - write the discriminant first, then the appropriate variant part.

  - read the discriminant value, explicitly set the discriminant field
    in the buffer variable and then read the appropriate variant part.

"Fixed" test case has been attached.

Presently my idea about the source of the bug is, that the compiler
generates wrong code for reading records with discriminants.

Before it sets the discriminant field in the variable, it doesn't run
appropriate finalizers and initializers on possibly changed variant
parts, but just sets the discriminant field and the invokes the read
procedure for the appropriate variant part. Of course at that time the
bit patterns in record representation are not appropriate for the
discriminant (the representation is invalid) but mostly that doesn't
matter since the invalid representation is overwritten anyway. It does
matter though in the case that the variant part visible after changing
the discriminant value contains fields with controlled data types:
Then finalizers are run on invalid variable content. In my case that
triggered a problem in the underlying libc malloc().

The problem should only happen if there are variant parts where a
variant part has fields with finalizers _AND_ the representation
doesn't overlap with that of the other variant parts (in my test case
the problem goes away if the fields with finalizers are just 2
Unbounded_Strings, one at the beginning of every variant part, which
could be explained by the finalizer running as a finalizer of the
wrong variant part but still being a finalizer of Unbounded_String and
thus correctly finalizing the Unbounded_String in the now hidden
variant part.)

Depending on the finalizers all that leads to erronous memory
deallocation or that some finalization action is dropped (I've not
verfied this, but I predict that will probably happen).

The bug should in example result in memory leaks if the variant part
incoreectly hidden during reading contains finalizers concerned with
freeing memory which then are not run.

All that is conjecture at the moment but well in agreement with the
evidence so far.


Regards -- Markus


----

    with Ada.Streams.Stream_IO; use  Ada.Streams.Stream_IO;
    with Ada.Strings.Unbounded; use Ada.Strings.Unbounded;

    procedure Demo.Bug3 is

       type Customer_Description( Is_Company : Boolean := True ) is record

          case Is_Company Is

             when  True   =>

                Foo                 : Integer := 0;       -- remove these and the
                Bar                 : Integer := 0;       -- SIGSEGV goes away
                Company_Name        : Unbounded_String ;

             when  False  =>

                Persons_Name        : Unbounded_String;

             when   others  =>  null;
          end case;
       end record;

       procedure Write_Customer_Description
         ( S : access Ada.Streams.Root_Stream_Type'Class;
           R : in Customer_Description
         );

       procedure Read_Customer_Description
         ( S : access Ada.Streams.Root_Stream_Type'Class;
           R : out Customer_Description
         );


       for Customer_Description'Write use Write_Customer_Description;
       for Customer_Description'Read  use Read_Customer_Description;


       procedure Set_Zugang ( D :  in out Customer_Description ; Z : Boolean ) is begin

          if Z /= D.Is_Company then

             case Z is

                when True      =>
                   declare New_D : Customer_Description(True);
                   begin
                      D := New_D ;
                   end;

                when False  =>
                   declare New_D : Customer_Description(False);
                   begin   D := New_D ; end;

             end case;
          end if;
       end;


       procedure Write_Customer_Description
         ( S : access Ada.Streams.Root_Stream_Type'Class;
           R : in Customer_Description
         )
       is begin
          Boolean'Write(S,R.Is_Company);
          case R.Is_Company is

             when True =>
                Integer'Write( S, R.Foo );
                Integer'Write( S, R.Bar );
                Unbounded_String'Write( S, R.Company_Name );

             when False =>
                Unbounded_String'Write( S, R.Persons_Name );
          end case;
       end;


       procedure Read_Customer_Description
         ( S : access Ada.Streams.Root_Stream_Type'Class;
           R : out Customer_Description
         )
       is
          B : Boolean;
       begin
          Boolean'Read(S,B);
          Set_Zugang( R, B);

          case R.Is_Company is

             when True =>
                Integer'Read( S, R.Foo );
                Integer'Read( S, R.Bar );
                Unbounded_String'Read( S, R.Company_Name );

             when False =>
                Unbounded_String'Read( S, R.Persons_Name );
          end case;
       end;


       procedure Write_Record
       is
         F : File_Type;
         S : Stream_Access;
         R : Customer_Description;
       begin
          Create( F , Name => "tmp-bug3" );
          S := Stream(F);
          Set_Zugang(R, False);                   -- remove this and the SIGSEGV goes away

          for I in 1 .. 400 loop
             Customer_Description'Write(S,R);     -- [1a]
          end loop;

          Close(F);
       end;


       procedure Get_Record
       is
          F : File_Type;
          S : Stream_Access;
       begin

          Open( F , Mode => In_File, Name => "tmp-bug3" );
          S := Stream(F);

          for I in 1 .. 400 loop
             declare R : Customer_Description;
             begin
                Customer_Description'Read(S,R);        -- [1b]
             end;
          end loop;

          Close( F );
       end;

       R : Customer_Description;

    begin
       Write_Record;
       Get_Record;
    end;

Possible memory leaks when reading/writing variant records

[M E Leypold]

Dear All,

For the record and not to let that get in lost in the longer post: The
ideas I've got about the source of the problem with reading and
writing variant record with finalizers leads me to the hypothesis that
reading and writing variant records with Unbounded_String fields in
it, might lead to memory leaks.

(In GNAT 3.15p).

More generally it would lead to resources not properly freed or finalized
especially in case where one doesn't get Storage_Error(s) or
Constraint_Error(s) because invalid representations are being
finalized.

See my recent post(s) about that problem.

Regards -- Markus

Re: Compiler Bug or what I'm doing wrong?

[Stephen Leake]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> + GPL editions compilers still look more buggy than 3.15p. GPL 2005 is
> definitely worse. 

Well, that may be true for your applications.

I encountered no bugs with GPL 2006; while 3.15p has significant bugs.

In a system as complex as a compiler, different people will have
different problems.
-- 
-- Stephe

Re: Compiler Bug or what I'm doing wrong?

[Dmitry A. Kazakov]

On Fri, 23 Jun 2006 08:26:32 -0400, Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> + GPL editions compilers still look more buggy than 3.15p. GPL 2005 is
>> definitely worse. 
> 
> Well, that may be true for your applications.
> 
> I encountered no bugs with GPL 2006; while 3.15p has significant bugs.
> 
> In a system as complex as a compiler, different people will have
> different problems.

Yes. Note, I didn't say "is more boggy." I did "looks more buggy."

BTW, my experience with GCC 4.0.2 (20051125) GNAT was rather positive. Guys
at sourceforge are doing a great job. Many thanks to them.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Compiler Bug or what I'm doing wrong?

[Alex R. Mosteo]

M E Leypold wrote:

> "Alex R. Mosteo" <devnull@mailinator.com> writes:
> 
>> I'm now, for example, facing a spurious exception case when switching
>> from GNAT GPL'05 to GPL'06, only when certain compiler switches are used.
>> I have
> 
> Have you tried to run that with a debugger? In my case I had
> exceptions first and only when running that with the debugger, I found
> that it was a SIGSEGV which got translated into a PROGRAM_ERROR by the
> signal handler and the run time since this happened in a finalizer.

I rarely use the debugger, I've got really used not to depend on it, though
certainly it's another tool not to be despised.

>> already found a workaround, and I even know that the problem is related
>> with interfaces, but I fear that the effort to isolate it will be a waste
>> of time. So the temptation to move on is big...
> 
> In my case: I think I have found a workaround (if my guess on the
> nature of the error is correct) and I'll post it here as a reference
> for the next users if it actually works.
> 
> In my opinion, documentation of "known bugs" and "proved workarounds"
> are almost as valuable as fixes. At least they'll spare other users
> the time (a) to form suspicions themselves and (b) to think about
> workarounds themselves.

Completely agree. When one has suffered from obscure bugs, it's inevitable
not to think that way. One would desire that they were listed in the
compiler documentation.

> It's a pity that GNAT (at least 3.15p? I'm repeating myself ...),
> doesn't have some kind of community support side where things as these
> could be collected. Or is there such a site?

Well, as pointed there's the debian tracker. Though it's no use if you don't
know about it, and even then I wonder how much it can help for other
platforms like windows.

My worst experience was when I got hit by the "sleeping tasks" bug which
only affected windows 3.15p version. After many hours of hunting with the
help of the Gnat list users (it existed by then), it turned out that it was
a real bug (I doubted it for some time) and that several people here knew
about it (but none in the gnat list!). I had been hesitant to ask in c.l.a.
for a gnat-specific question. After the experience I wouldn't be so timid.

Certainly, the http://gnuada.sf.net site seems a good place to centralize
reports (apart, of course, of reporting them to debian for the linux
branches). I guess I'll start to send there too my reports.

> For now I'm "misusing" c.l.a. for that but I wonder wether that was
> right.

It's right in my oppinion to discuss it here, maybe others disagree.
Although, for history, I'd prefer if everyone used the site mentioned
above, for example.

>> This post is really just to show my "condolences" and support. Best luck,
> 
> Hey, thanks :-)). And good luck with your problem too.

Thanks, it's already solved.

Re: Compiler Bug or what I'm doing wrong?

[Alex R. Mosteo]

Stephen Leake wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> + GPL editions compilers still look more buggy than 3.15p. GPL 2005 is
>> definitely worse.
> 
> Well, that may be true for your applications.
> 
> I encountered no bugs with GPL 2006; while 3.15p has significant bugs.

I guess you've not tried to make significant use of interfaces? In a week of
gpl2006 usage I've hit three bugs there.

On the other hand, dot notation for tagged objects seems much more robust,
not a single quirk for now (whereas 2005 was plagued).

I had (as noted in another thread) very bad experiences with 3.15p for
windows because of a single hidden bug so, in comparison, bugs that blow
right in your face don't bother me that much.

Apart from that, I'd say that gnat is getting better and better fast with
each release, and now that Ada05 is being frozen I bet in few time the gcc
branch will get really interesting.

> In a system as complex as a compiler, different people will have
> different problems.

Re: Compiler Bug or what I'm doing wrong?

[Alex R. Mosteo]

Alex R. Mosteo wrote:

> It's right in my oppinion to discuss it here, maybe others disagree.
> Although, for history, I'd prefer if everyone used the site mentioned
> above, for example.

After inspecting more carefully the gnuada site, I believe that the bug
tracker is for their installation packages, right?

Maybe the 3rd party bugs section could serve.

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[Dmitry A. Kazakov]

On 23 Jun 2006 11:55:23 +0200, M E Leypold wrote:

> I'm attaching a smaller (and now self contained test case!) for the
> SIGSEGV whil reading/writing varaint records which I wrote about
> earlier.
> 
> Some data:
> 
>  1. Gnat 3.15p on Debian Sarge.
>  2. Running the attached program wil result in a SIGSEGV in a finalizer.
> 
> I'm also attaching a short backtrace.

Well, it looks like a bug to me.

ARM 13.13.2 (9) reads:

   "If T is a discriminated type, discriminants are included only if they
have defaults."

which assumes that if they have, then 'Write/'Read should handle them
properly. When the discriminant is set to false before making 'Read, the
program works as expected.

The problem is essentially:

type Foo (C : Boolean := True) is ...;

X : Foo (False);
...
Foo'Write (S, X);


Y : Foo (True);
...
Foo'Read (S, Y); -- Boom

Any language lawyers, here?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 23 Jun 2006 11:55:23 +0200, M E Leypold wrote:
> 
> > I'm attaching a smaller (and now self contained test case!) for the
> > SIGSEGV whil reading/writing varaint records which I wrote about
> > earlier.
> > 
> > Some data:
> > 
> >  1. Gnat 3.15p on Debian Sarge.
> >  2. Running the attached program wil result in a SIGSEGV in a finalizer.
> > 
> > I'm also attaching a short backtrace.
> 
> Well, it looks like a bug to me.

Thanks for the confirmation :-).

> 
> ARM 13.13.2 (9) reads:
> 
>    "If T is a discriminated type, discriminants are included only if they
> have defaults."

I understood it like this: If the discrimant has defaults the type is
definite (translate that as "has fixed memory allocation
requirements"). Then 'Read is expected to handle the type. Else (no
default discriminant) the type is indefinite ("no fixed memory
allocation requirement") and 'Input would be the appropriate function
to read from a Stream, but it would essentially read the discriminats,
allocate memory and then invoke 'Read. 

If my understanding is wrong here, please correct me anyone.
 
> which assumes that if they have, then 'Write/'Read should handle them
> properly. When the discriminant is set to false before making 'Read, the
> program works as expected.

> 
> The problem is essentially:

Yes ...

> 
> type Foo (C : Boolean := True) is ...;
> 
> X : Foo (False);
> ...
> Foo'Write (S, X);
> 
> 
> Y : Foo (True);
> ...
> Foo'Read (S, Y); -- Boom


But not quite: A problem only turns up if there are finalizers in
variant parts. The compiler generated 'read procedure must of course
run the finalizer correctly when overwriting the record fields.

I hypothesized that in 

    type Foo (C : Boolean := True) is record

         case C is 
              when True  => .... -- [1]
              when False => .... -- [2]
         end case;

    end record;

actually the finalizers in the wrong variant part are run if the
default disriminant is different from the discriminant read from the
stream. So, if the discriminant read from the strem is False, it would
be actually the finalizers in [2] that are run.

Interesting enough there are a huge number of cases where this is of
no consequence whatsoever, which might account for the fact that this
bug is in 3.15p (which after all has gone through some years of
development and the bug is elementary, if tricky):

 - If there are no controlled types in parts [1] or [2].

 - If the position of the representations of the controlled data fields in [1]
   and [2] coincide and they are of the same type.

 - If the controlled type is not freeing resources.

 - If the controlled type is in [1]: This results in a slow ressource
   leak which probably stays undetected for a long time.

The only case where things go really bad, and become conspicous to the
compiler user, is when the corntrolled type is in [2] and frees
ressources which can't be freed doubly or where there can be invalid
resource handles (like null pointers to malloc()).

The hypothesis that the wrong finalizers are being run could be tested
of course (by using a custom controlled type), but I haven't done it
yet (fixing my application or getting a new Gnat as obviously
priority).

Regards -- Markus

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[Dmitry A. Kazakov]

On 24 Jun 2006 14:27:16 +0200, M E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> ARM 13.13.2 (9) reads:
>> 
>>    "If T is a discriminated type, discriminants are included only if they
>> have defaults."
> 
> I understood it like this: If the discrimant has defaults the type is
> definite (translate that as "has fixed memory allocation
> requirements"). Then 'Read is expected to handle the type. Else (no
> default discriminant) the type is indefinite ("no fixed memory
> allocation requirement") and 'Input would be the appropriate function
> to read from a Stream, but it would essentially read the discriminats,
> allocate memory and then invoke 'Read. 

Input is always appropriate, Read only if constraints are fixed during
object life time [informally].

BTW, I wouldn't use discriminants with defaults, and in any case, would use
Input for them. Further, in this particular case, I'd expect Read be less
effective than Input:

1. You have the discriminant stored anyway (that was the choice about
having the defaults), so you cannot use one stored value of the
discriminant for all 400 fields, even if they had it same.

2. Read means that you have one extra initialize / finalize pair. Input
does not:

declare
   X : Foo renames Foo'Input (S); -- Initializes only once
begin

[...]
> The hypothesis that the wrong finalizers are being run could be tested
> of course (by using a custom controlled type), but I haven't done it
> yet (fixing my application or getting a new Gnat as obviously
> priority).

My experience with GNAT tells me: slowly, don't hurry. You never know which
new bug it could have. (:-()

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> BTW, I wouldn't use discriminants with defaults, 

I'm perhaps misuing dicriminants anyway in that application. But they
need to have defaults, since the disriminated records are fields in
another record. Like

  type All_We_Know ( Internal_Data_Available : Boolean := True ) is record 


    case Internal_Data_Available is

         when True  =>  Secret_Data : ... ;

         ...
  end record;

  
  type ... is record 

    Things_Known : All_We_Konw;

    ...

  end record;
 
(Ok, stupid example, but you get ist: Data not to be given to an
 external data processing application can be supressed by the
 discriminant).


> and in any case, would use
> Input for them. 


I tried to do that, but that didn't fix the problem. I also wouldn't
expect that: According to Barnes Input most probably uses Read.


> 1. You have the discriminant stored anyway (that was the choice about
> having the defaults), so you cannot use one stored value of the
> discriminant for all 400 fields, even if they had it same.

Oops. That I don't understand.

> 2. Read means that you have one extra initialize / finalize pair. Input
> does not:

I don't care. Input is slow anyway and doesn't happen so often :-).

> 
> declare
>    X : Foo renames Foo'Input (S); -- Initializes only once
> begin
> 
> [...]
> > The hypothesis that the wrong finalizers are being run could be tested
> > of course (by using a custom controlled type), but I haven't done it
> > yet (fixing my application or getting a new Gnat as obviously
> > priority).
> 
> My experience with GNAT tells me: slowly, don't hurry. You never know which
> new bug it could have. (:-()

One reason why I stayed with 3.15p up to now. But now I've a record
with discriminants whose fields are records with discrimants and so
on, around 170 fields all in all and I dread the task of writing input
and out procedures for them. Maybe I dread Gnatgcc less. I don't know
yet.

Regards -- Markus

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[Dmitry A. Kazakov]

On 24 Jun 2006 15:53:32 +0200, M E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> BTW, I wouldn't use discriminants with defaults, 
> 
> I'm perhaps misuing dicriminants anyway in that application. But they
> need to have defaults, since the disriminated records are fields in
> another record. Like
> 
>   type All_We_Know ( Internal_Data_Available : Boolean := True ) is record 
>     case Internal_Data_Available is
>          when True  =>  Secret_Data : ... ;
>          ...
>   end record;
> 
>   type ... is record 
>     Things_Known : All_We_Konw;
>     ...
>   end record;
>  
> (Ok, stupid example, but you get ist: Data not to be given to an
>  external data processing application can be supressed by the
>  discriminant).

All_We_Know looks much like a handle. Then I'd try to make it more OO, if
you aren't allergic to it. What about tagged types? (:-))

>> and in any case, would use
>> Input for them. 
> 
> I tried to do that, but that didn't fix the problem. I also wouldn't
> expect that: According to Barnes Input most probably uses Read.

Or a part of it. Anyway, try this:

with Ada.Text_IO;
with Ada.Streams.Stream_IO;  use Ada.Streams.Stream_IO;
with Ada.Strings.Unbounded;  use Ada.Strings.Unbounded;

procedure Bug3 is

  type Customer_Description (Is_Company : Boolean := True) is record
     case Is_Company Is
        when True =>
           Foo          : Integer := 0;       -- remove these and the
           Bar          : Integer := 0;       -- SIGSEGV goes away
           Company_Name : Unbounded_String ;
        when False =>
           Persons_Name : Unbounded_String;
        when others  =>  null;
     end case;
  end record;

  procedure Set_Zugang (D : in out Customer_Description; Z : Boolean) is
  begin
     if Z /= D.Is_Company then
        case Z is
           when True =>
              declare
                 New_D : Customer_Description (True);
              begin
                 D := New_D;
              end;
           when False  =>
              declare
                 New_D : Customer_Description (False);
              begin
                 D := New_D;
              end;
        end case;
     end if;
  end;

  procedure Write_Record is
     F : File_Type;
     S : Stream_Access;
     R : Customer_Description;
  begin
     Create (F, Name => "tmp-bug3");
     S := Stream (F);
     Set_Zugang (R, False);                   -- remove this and the
SIGSEGV goes away

     for I in 1 .. 400 loop
        Customer_Description'Output (S,R);     -- [1a]
     end loop;
     Close (F);
  end;

  procedure Get_Record is
     F : File_Type;
     S : Stream_Access;
  begin
     Open (F, Mode => In_File, Name => "tmp-bug3" );
     S := Stream (F);
     for I in 1 .. 400 loop
        declare
           R : Customer_Description renames
                  Customer_Description'Input (S);
        begin
           Ada.Text_IO.Put_Line ("Read" & Integer'Image (I));
        end;
     end loop;
     Close (F);
  end;

begin
  Write_Record;
  Get_Record;
end;

It should work with GNAT 3.15p / Windows.

>> 1. You have the discriminant stored anyway (that was the choice about
>> having the defaults), so you cannot use one stored value of the
>> discriminant for all 400 fields, even if they had it same.
> 
> Oops. That I don't understand.

If the discriminant had no default, then Write would not store it. So if
all 400 elements had the same value of the discriminant, you could first
store its value manually (Boolean'Write) and then use 'Write for each
element. When reading you'd read the discriminant value once and then use
Read on a variable constrained to that value:

type Foo (C : Boolean) is ...;

Boolean'Write (S, False);
for I in ... loop
   Foo'Write (S, Get_R (I)); -- I know that all C's are same
end loop;

declare
   C : Boolean;
begin
   Boolean'Read (S, C);
   declare
      R : Foo (C);
   begin
      for I in ... loop
         Foo'Real (S, R); -- I know that all C's are same
      end loop;

>> 2. Read means that you have one extra initialize / finalize pair. Input
>> does not:
> 
> I don't care. Input is slow anyway and doesn't happen so often :-).

So it is safe to use it, at least to work the bug around.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 24 Jun 2006 15:53:32 +0200, M E Leypold wrote:
> 
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> > 
> >> BTW, I wouldn't use discriminants with defaults, 
> > 
> > I'm perhaps misuing dicriminants anyway in that application. But they
> > need to have defaults, since the disriminated records are fields in
> > another record. Like
> > 
> >   type All_We_Know ( Internal_Data_Available : Boolean := True ) is record 
> >     case Internal_Data_Available is
> >          when True  =>  Secret_Data : ... ;
> >          ...
> >   end record;
> > 
> >   type ... is record 
> >     Things_Known : All_We_Konw;
> >     ...
> >   end record;
> >  
> > (Ok, stupid example, but you get ist: Data not to be given to an
> >  external data processing application can be supressed by the
> >  discriminant).
> 

> All_We_Know looks much like a handle. Then I'd try to make it more OO, if

No. That's just a stupid name. Actually it is an aggregate of
information about a specific "case" which is not allowed to leave this
specific office (privacy policy!) but the rest of the data is sent to
a central office for statistical evaluation. No handle. The data in
the record refers to the case.

> you aren't allergic to it. What about tagged types? (:-))

Next time :-) (if there is a next time for an Ada project). Problem
with this data structure is, that it is at the core of the application
and rather specific. I don't dare ripping it out now. 

I followed Barnes' advice here: "wether it is appropriate to use a
variant or tagged type, the key consideration is mutability". 

>   procedure Get_Record is
>      F : File_Type;
>      S : Stream_Access;
>   begin
>      Open (F, Mode => In_File, Name => "tmp-bug3" );
>      S := Stream (F);
>      for I in 1 .. 400 loop
>         declare
>            R : Customer_Description renames
>                   Customer_Description'Input (S);

Oops. My, that is a dirty trick -- but how do I return R? Hm, yes I
can see how that would work. Perhaps :-).  I'll see how I can fit that
into the database module.

>         begin
>            Ada.Text_IO.Put_Line ("Read" & Integer'Image (I));
>         end;
>      end loop;
>      Close (F);
>   end;
> 
> begin
>   Write_Record;
>   Get_Record;
> end;
> 
> It should work with GNAT 3.15p / Windows.





> 
> >> 1. You have the discriminant stored anyway (that was the choice about
> >> having the defaults), so you cannot use one stored value of the
> >> discriminant for all 400 fields, even if they had it same.
> > 
> > Oops. That I don't understand.
> 
> If the discriminant had no default, then Write would not store it. So if

But it must. I don't know at the place whre the record is read which
discriminant the record had. There can even be different discriminant
in the records in the database (which you can't see in this example :-).


> all 400 elements had the same value of the discriminant, you could first
> store its value manually (Boolean'Write) and then use 'Write for each
> element. When reading you'd read the discriminant value once and then use
> Read on a variable constrained to that value:


Ah no. Unfortunately I have many of discriminants in many places (they
reflect a more complicated business logic when data can/must be
available) and they can all change independently.

> So it is safe to use it, at least to work the bug around.

Yep. At least until an new Gnat ciomes up for me.

Regards and thanks! Maybe your trick will spare me a lot of gray
hairs.


Regards -- Markus

Re: Compiler Bug or what I'm doing wrong?

[Simon Wright]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> Alex R. Mosteo wrote:
>
>> It's right in my oppinion to discuss it here, maybe others
>> disagree.  Although, for history, I'd prefer if everyone used the
>> site mentioned above, for example.
>
> After inspecting more carefully the gnuada site, I believe that the
> bug tracker is for their installation packages, right?

Yes

> Maybe the 3rd party bugs section could serve.

I would have thought something starting at the GNATP page (== 3.15p)
would be appropriate for that compiler, similar for others. This is at
http://gnuada.sourceforge.net/pmwiki.php/Packages/GNATP reached from
the Packages section of the first page.

Re: Compiler Bug or what I'm doing wrong?

[M E Leypold]

Simon Wright <simon@pushface.org> writes:

> "Alex R. Mosteo" <devnull@mailinator.com> writes:
> 
> > Alex R. Mosteo wrote:
> >
> >> It's right in my oppinion to discuss it here, maybe others
> >> disagree.  Although, for history, I'd prefer if everyone used the
> >> site mentioned above, for example.
> >
> > After inspecting more carefully the gnuada site, I believe that the
> > bug tracker is for their installation packages, right?
> 
> Yes
> 
> > Maybe the 3rd party bugs section could serve.
> 
> I would have thought something starting at the GNATP page (== 3.15p)
> would be appropriate for that compiler, similar for others. This is at
> http://gnuada.sourceforge.net/pmwiki.php/Packages/GNATP reached from
> the Packages section of the first page.


I agree and possibly will post my bug report there. This site isn't
used for bugtracking currently, so I asked wether there is a better
place. If not, that sit will do and we'll see what comes from it.

Regards -- Markus

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

Before trying the workaround

>         declare
>            R : Customer_Description renames
>                   Customer_Description'Input (S);

suggested by Dmitry, I thought I would try to trace which
finalizers/initializers are excuted when. I first got a case where
more finalizers than I expected got executed and than all of a sudden
a case where absolutely now finlizers are executed during 'Read (but
the discriminant is changed and there are controlled fields in the
variant part. Oops. I'll post more result when they have become more
deterministic.

Regards -- Markus

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[Dmitry A. Kazakov]

On 24 Jun 2006 22:22:30 +0200, M E Leypold wrote:

> I followed Barnes' advice here: "wether it is appropriate to use a
> variant or tagged type, the key consideration is mutability". 

True [mutability of class instances] Handles to tagged types is another way
to have mutable class-wide.
 
>>   procedure Get_Record is
>>      F : File_Type;
>>      S : Stream_Access;
>>   begin
>>      Open (F, Mode => In_File, Name => "tmp-bug3" );
>>      S := Stream (F);
>>      for I in 1 .. 400 loop
>>         declare
>>            R : Customer_Description renames
>>                   Customer_Description'Input (S);
> 
> Oops. My, that is a dirty trick -- but how do I return R? Hm, yes I
> can see how that would work. Perhaps :-).  I'll see how I can fit that
> into the database module.

Hey, it is not a trick, but a nice pattern! I am using it quite often, and
count it for a good style.

Anyway, the following will work as well:

  procedure Get_Record is
     F : File_Type;
     S : Stream_Access;
     R : Customer_Description;
  begin
     Open (F, Mode => In_File, Name => "tmp-bug3" );
     S := Stream (F);
     for I in 1 .. 400 loop
        R := Customer_Description'Input (S);
        Ada.Text_IO.Put_Line ("Read" & Integer'Image (I));
     end loop;
     Close (F);
  end;

As far as I can tell, the bug is not in finalization. It is rather in
absence of. It seems that GNAT does *not* make it in Read when the
discriminant gets changed *by* Read. Then, later, another finalization
discovers rubbish. That never can happen when Input is used. So, it is safe
to use Input in all combinations. Just a guess.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 24 Jun 2006 22:22:30 +0200, M E Leypold wrote:
> 
> > I followed Barnes' advice here: "wether it is appropriate to use a
> > variant or tagged type, the key consideration is mutability". 
> 
> True [mutability of class instances] Handles to tagged types is another way
> to have mutable class-wide.
>  
> >>   procedure Get_Record is
> >>      F : File_Type;
> >>      S : Stream_Access;
> >>   begin
> >>      Open (F, Mode => In_File, Name => "tmp-bug3" );
> >>      S := Stream (F);
> >>      for I in 1 .. 400 loop
> >>         declare
> >>            R : Customer_Description renames
> >>                   Customer_Description'Input (S);
> > 
> > Oops. My, that is a dirty trick -- but how do I return R? Hm, yes I
> > can see how that would work. Perhaps :-).  I'll see how I can fit that
> > into the database module.
> 
> Hey, it is not a trick, but a nice pattern! I am using it quite often, and
> count it for a good style.

I didn't know that one could rename function results :-). Never had
seen that. But now that I see it, it makes a lot of sense. My
experiments indicate that a lot less finalizers/initializers run with
that pattern. That is good and I'll keep that in mind.

Also, thinking about it, that should be solution to initializing
limited values, wich I have been looking for and never foudn it (AFAIK
Barnes is silent on that). I assume the following would work (with
B_Type being a limited type)?

   declare B : B_Type renames Make_a_B(...);

> Anyway, the following will work as well:


Unfortunately all that doesn't remove my original Bug. The original
program (not the simplified example) has a more complex data structure
and a kind of filesystem/database. If I replace Read/Write by
Input/Output there, the bug persists. 

In the really simple example I submitted, tha bug goes away, but I
consider this accidental (due to the Heisenbug nature of
initialization- and malloc()-related bugs). When trying to replace the
Unbounded_String(s) in the example by Controlled types A_Class and
B_Class which print when their finalizes/initializers/asjustment are
run, I get mixed, partially non reproducible results:

  - I had a case where it seemed, that one initializer too many is
    run. When trying to change the tracing that effect vanished and
    couldn't be restored.

  - I had a case where during Read no initializers/finalizers whatever
    where run, but the discriminant was changed. The finalizer for the
    non-visible variant part (non-visible with the changed
    dioscriminant) was run at block exit but on the data content of
    the visible variant part.

All that indicates that the problem in question is not simply a
problem ion the order of operations as a surmised before. It looks a
bit like a caching problem: When at block exit the runtime examines
the discriminant it seems to have retained the old value somewhere and
act on that. I hoped, that switching of optimization (-O0) would make
that kind of bug go away, but didn't change anything.

I'm stuck for the moment. Simple workarounds obviously don't cover the
more complex cases (variant parts in varaint parts in variant
parts). Either I will have to write IO-procedure manually, or I'll
have to change to another compiler. Well.

Regards -- Markus

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[M E Leypold]

Dear All,

Just wanted to report that I've been able to reproduce the problem
with Gcc gnat 3.4 (on Debian/Sarge). Doesn't really look like it has
been fixed 'long ago'. Not this one, unfortunately.

Regards -- Markus

Re: A smaller self contained test case. Was: Compiler Bug or what I'm doing wrong?

[Martin Dowie]

M E Leypold wrote:
> I didn't know that one could rename function results :-). Never had
> seen that. But now that I see it, it makes a lot of sense. My
> experiments indicate that a lot less finalizers/initializers run with
> that pattern. That is good and I'll keep that in mind.

Been able to do that since Ada83. Handy! :-)

Cheers
-- Martin

Re: Compiler Bug or what I'm doing wrong?

[Ludovic Brenta]

M E Leypold writes :
> > > After inspecting more carefully the gnuada site, I believe that the
> > > bug tracker is for their installation packages, right?
> >
> > Yes
> >
> > > Maybe the 3rd party bugs section could serve.
> >
> > I would have thought something starting at the GNATP page (== 3.15p)
> > would be appropriate for that compiler, similar for others. This is at
> > http://gnuada.sourceforge.net/pmwiki.php/Packages/GNATP reached from
> > the Packages section of the first page.
>
> I agree and possibly will post my bug report there. This site isn't
> used for bugtracking currently, so I asked wether there is a better
> place. If not, that sit will do and we'll see what comes from it.

I would suggest the Debian bug tracker instead; not because I'm trying
to promote Debian, but because the Debian BTS already has 200 bugs
filed in it or so. The community will be better served by one central
bug database than by several disjoint ones. I specifically encourage
anyone to submit bugs there, even if they do not use Debian. Similarly,
my patches that fix several bugs in 3.15p are available to all.

The only reason why I started using the Debian BTS back in 2003 was
because no other public database existed at that time. So, I claim
precedence :)

To use the Debian BTS, you only need a mail client; each bug is a
mailing list and the archives are available in mbox format.

-- 
Ludovic Brenta.

Re: Compiler Bug or what I'm doing wrong?

[M E Leypold]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> writes:

> M E Leypold writes :
> > > > After inspecting more carefully the gnuada site, I believe that the
> > > > bug tracker is for their installation packages, right?
> > >
> > > Yes
> > >
> > > > Maybe the 3rd party bugs section could serve.
> > >
> > > I would have thought something starting at the GNATP page (== 3.15p)
> > > would be appropriate for that compiler, similar for others. This is at
> > > http://gnuada.sourceforge.net/pmwiki.php/Packages/GNATP reached from
> > > the Packages section of the first page.
> >
> > I agree and possibly will post my bug report there. This site isn't
> > used for bugtracking currently, so I asked wether there is a better
> > place. If not, that sit will do and we'll see what comes from it.
> 
> I would suggest the Debian bug tracker instead; not because I'm trying
> to promote Debian, but because the Debian BTS already has 200 bugs
> filed in it or so. 

I'll try to file the bug in both places. IMHO gnuada.sourceforge.net
would be the logical place for tracking bugs in community supported
Ada software, but since nobody has reported anything there yet, one
can hardly expect anyone looking there for solutions.

> The community will be better served by one central
> bug database than by several disjoint ones. 

I completely agree. I think the situation is a bit confused presently
because of the transition between p-releases and gcc gnat: For gcc
gnat the upstream source for the debian releases would come from
http://gcc.gnu.org/ and their BTS would be the first to report bugs
to. Debian BTS would either mostly refer to bugs in the gcc BTS or to
packaging defects.

(A propos packaging defects: libgtkada2-dev in Sarge absolutely
insists on getting 3.15p installed with it, despite the fact that
gnat-3.4 also "provides gnat". Superficially, from the dependencies
listing, I cannot understand why that is so and I also wonder wether
this is intended (that gtkada can only be used with 3.15p at debian).

I think the situation wrt to where to report bugs will become more
clearly defined when the transition to gccada has been done.

> I specifically encourage anyone to submit bugs there, even if they
> do not use Debian. Similarly, my patches that fix several bugs in
> 3.15p are available to all.

Yes, I already perceived that Debian is the only open platform where
I'd say that Gnat is actually supported in sense.

> The only reason why I started using the Debian BTS back in 2003 was
> because no other public database existed at that time. So, I claim
> precedence :)

You'll get it.

Regards -- Markus

[Ada in Debian] GtkAda and GNAT versions

[Ludovic Brenta]

M E Leypold writes :
> (A propos packaging defects: libgtkada2-dev in Sarge absolutely
> insists on getting 3.15p installed with it, despite the fact that
> gnat-3.4 also "provides gnat".

This is a bug in the package gnat-3.4; it should not provide gnat.  I
think the reason why it does is because it can compile gnat, gnat-3.3
and gnat-3.4 from sources. But that's now irrelevant, since gnat-3.3
and gnat-3.4 have been removed from Debian Etch. I never spent much
time maintaining either gnat-3.3 or gnat-3.4.

> Superficially, from the dependencies
> listing, I cannot understand why that is so and I also wonder wether
> this is intended (that gtkada can only be used with 3.15p at debian).

Yes, this is intended. Each new version of GNAT breaks binary
compatibility. All -dev packages provide Ada library information (.ali)
files, static libraries (.a) and shared libraries (.so), which only
work with the version of GNAT they've been created with. So, for
example, the .ali files provided in libgtkada2-dev are only good for
gnat, not for gnat-3.4 (GNAT enforces this by means of checksums to
ensure consistency of the final executable, per ARM 10.2(27)).

As a consequence, all -dev packages in Debian require gnat, so that you
can use all libraries in the same program.

I don't have the manpower to maintain several versions of GNAT in
parallel, or provide different binary packages of each library for each
version of GNAT.

> I think the situation wrt to where to report bugs will become more
> clearly defined when the transition to gccada has been done.

Not really; the Debian documentation says you should report bugs to the
Debian BTS, and nowhere else. The package maintainer then decides
whether the bug comes from the packaging, or from upstream. In the case
of gnat 3.15p, there simply is no upstream bug database. In the case of
gnat-4.1 (the default in Etch), we use GCC's bugzilla as the upstream
database.

>> I specifically encourage anyone to submit bugs there, even if they
>> do not use Debian. Similarly, my patches that fix several bugs in
>> 3.15p are available to all.
>
> Yes, I already perceived that Debian is the only open platform where
> I'd say that Gnat is actually supported in sense.

Thanks!

PS. I'd like to add this: people not using Debian are welcome to
reports bugs, but I'd ask them to state exactly what platform they're
using, as with any bug report, but also to check that their bug is not
already solved in Debian.

-- 
Ludovic Brenta.

Re: [Ada in Debian] GtkAda and GNAT versions

[M E Leypold]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> writes:

> M E Leypold writes :
> > (A propos packaging defects: libgtkada2-dev in Sarge absolutely
> > insists on getting 3.15p installed with it, despite the fact that
> > gnat-3.4 also "provides gnat".
> 
> This is a bug in the package gnat-3.4; it should not provide gnat.  I

The joke is: It works. After just breaking the dependencies I could
compile gtkada-programs with it (though all GtkAda package where
regenerated in situ then).

> think the reason why it does is because it can compile gnat, gnat-3.3
> and gnat-3.4 from sources. But that's now irrelevant, since gnat-3.3
> and gnat-3.4 have been removed from Debian Etch. I never spent much
> time maintaining either gnat-3.3 or gnat-3.4.

OK. I'v just finished building gcc-4.1.1. :-)


> > Superficially, from the dependencies
> > listing, I cannot understand why that is so and I also wonder wether
> > this is intended (that gtkada can only be used with 3.15p at debian).
> 
> Yes, this is intended. Each new version of GNAT breaks binary
> compatibility. All -dev packages provide Ada library information (.ali)
> files, static libraries (.a) and shared libraries (.so), which only
> work with the version of GNAT they've been created with. So, for
> example, the .ali files provided in libgtkada2-dev are only good for
> gnat, not for gnat-3.4 (GNAT enforces this by means of checksums to
> ensure consistency of the final executable, per ARM 10.2(27)).

Since I'm using -a (For regenerating Ada.Containers from source) my
libgtkada packages get also regenerated. 


> As a consequence, all -dev packages in Debian require gnat, so that you
> can use all libraries in the same program.
> 
> I don't have the manpower to maintain several versions of GNAT in
> parallel, or provide different binary packages of each library for each
> version of GNAT.

I'd perhaps be intrested to do that or to help here, if I'm staying
with Ada as my primary system language. At present though, the bugs
and the discussion here have cost me too much time.

> > I think the situation wrt to where to report bugs will become more
> > clearly defined when the transition to gccada has been done.
> 
> Not really; the Debian documentation says you should report bugs to the
> Debian BTS, and nowhere else. The package maintainer then decides
> whether the bug comes from the packaging, or from upstream. In the case
> of gnat 3.15p, there simply is no upstream bug database. In the case of
> gnat-4.1 (the default in Etch), we use GCC's bugzilla as the upstream
> database.
> 
> >> I specifically encourage anyone to submit bugs there, even if they
> >> do not use Debian. Similarly, my patches that fix several bugs in
> >> 3.15p are available to all.
> >
> > Yes, I already perceived that Debian is the only open platform where
> > I'd say that Gnat is actually supported in sense.
> 
> Thanks!
> 
> PS. I'd like to add this: people not using Debian are welcome to
> reports bugs, but I'd ask them to state exactly what platform they're
> using, as with any bug report, but also to check that their bug is not
> already solved in Debian.

Good.

Regards -- Markus

Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[M E Leypold]

Dear All,

I've been able to compile one of the smaller, selfcontained test cases
with gcc-4.1.1 and it looks as if the Read/Write bug has been
fixed. At least I don't get a SIGSEGV any more.

Unfortunately when compiling the larger program, I now get a bug box,
that starts like this:

  +===========================GNAT BUG DETECTED==============================+
  | 4.1.1 (i686-pc-linux-gnu) in create_tmp_var, at gimplify.c:410           |
  | Error detected at sf-choicetables.adb:485:1                              |


Whereas I'll be trying to report _that_ also to whereever, I'm rapidly
running out of temporal resources, so I'll not follow that new issue
to its logical conclusion.

Just as a message to all those that have been responding that I should
use a newer compiler:

 - gcc 3.4 hadn't fixed it yet.

 - With gcc-4.1.1 I first found a problem with the typing, then

 - I found the bug box above.

I've not been expecting anything else, since I've some experience with
maintaining gcc on various platforms and dread out of experience what
will happen if on tries to change the tool chain in just some hours.

Let that be a lesson to those that don't hold dear their old compiler
versions: Changing to new version will just get you new, different
sneaky bugs, not less :-).

Regards -- Markus

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[Alex R. Mosteo]

M E Leypold wrote:

> I've been able to compile one of the smaller, selfcontained test cases
> with gcc-4.1.1 and it looks as if the Read/Write bug has been
> fixed. At least I don't get a SIGSEGV any more.
> 
> Unfortunately when compiling the larger program, I now get a bug box,
> that starts like this:
> 
>   +===========================GNAT BUG
>   DETECTED==============================+
>   | 4.1.1 (i686-pc-linux-gnu) in create_tmp_var, at gimplify.c:410        
>   |   |
>   | Error detected at sf-choicetables.adb:485:1                           
>   |   |
> 
> 
> Whereas I'll be trying to report _that_ also to whereever, I'm rapidly
> running out of temporal resources, so I'll not follow that new issue
> to its logical conclusion.
> 
> Just as a message to all those that have been responding that I should
> use a newer compiler:
> 
>  - gcc 3.4 hadn't fixed it yet.
> 
>  - With gcc-4.1.1 I first found a problem with the typing, then
> 
>  - I found the bug box above.
> 
> I've not been expecting anything else, since I've some experience with
> maintaining gcc on various platforms and dread out of experience what
> will happen if on tries to change the tool chain in just some hours.

Last time I heard, Ada is not a release criterion for gcc. As I understand
it, this means that the gcc version, even if GMGPL, can be in any state. It
could be perfectly ok yesterday, and today be broken in subtle ways, and
this wouldn't alter the gcc releasing schedule.

It's for this reason, coupled with the fact that AdaCore endorsed versions
use 3.4.6 as backend and not 4.x, and with the fact that gnat is enduring
heavy changes due to the addition of 2005 features, that I hold very low
expectatives on the gcc-gnat, for the time being.

> Let that be a lesson to those that don't hold dear their old compiler
> versions: Changing to new version will just get you new, different
> sneaky bugs, not less :-).

Ah, the times when one never ever ran in a compiler bug...

Re: Compiler Bug or what I'm doing wrong?

[Simon Wright]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> writes:

> M E Leypold writes :
>> > > After inspecting more carefully the gnuada site, I believe that the
>> > > bug tracker is for their installation packages, right?

I wrote:

>> > Yes
>> >
>> > > Maybe the 3rd party bugs section could serve.
>> >
>> > I would have thought something starting at the GNATP page (== 3.15p)
>> > would be appropriate for that compiler, similar for others. This is at
>> > http://gnuada.sourceforge.net/pmwiki.php/Packages/GNATP reached from
>> > the Packages section of the first page.
>>
>> I agree and possibly will post my bug report there. This site isn't
>> used for bugtracking currently, so I asked wether there is a better
>> place. If not, that sit will do and we'll see what comes from it.
>
> I would suggest the Debian bug tracker instead; not because I'm
> trying to promote Debian, but because the Debian BTS already has 200
> bugs filed in it or so. The community will be better served by one
> central bug database than by several disjoint ones. I specifically
> encourage anyone to submit bugs there, even if they do not use
> Debian. Similarly, my patches that fix several bugs in 3.15p are
> available to all.

The only reason I suggested the gnuada site was that it's a wiki so
people could post their workrounds/experiences. If the Debian bug
tracker will do that, fine (and it's obviously better that bugs should
eb posted _somewhere_!)

Re: Compiler Bug or what I'm doing wrong?

[Ludovic Brenta]

Simon Wright <simon@pushface.org> writes:
> The only reason I suggested the gnuada site was that it's a wiki so
> people could post their workrounds/experiences. If the Debian bug
> tracker will do that, fine (and it's obviously better that bugs
> should eb posted _somewhere_!)

Yes, as I said, every bug is a mailing list.  Just send mail to
nnn@bugs.debian.org (replace nnn with the bug number), and voilà.

More at http://www.debian.org/Bugs/Reporting and
http://www.debian.org/Bugs/Access

-- 
Ludovic Brenta.

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[M E Leypold]

"Alex R. Mosteo" <devnull@mailinator.com> writes:

> > 
> > I've not been expecting anything else, since I've some experience with
> > maintaining gcc on various platforms and dread out of experience what
> > will happen if on tries to change the tool chain in just some hours.
> 
> Last time I heard, Ada is not a release criterion for gcc. As I understand

Oh d***. I compile a lot of real live code. So I'm not even sure
wether my program isn't illegal somwhere but got accepted by
unjustifiedly by 3.15p.

> it, this means that the gcc version, even if GMGPL, can be in any state. It

I had heard good things about 4.1.1 here, which was the reason I just
tested that avenue of getting rid of the Read/Write bug with variant
records. Since it doesn't work I'll concentrate on a more immediate
workaround and see, wether I cannot help Debain people to get 4.1.1
into Etch and migrate then (mind you, I'm nor actually promising any
help here just now, since GtkAda, this bug and all the "it's not fair
to work with free software", whatever, did cost me way too much time).

> could be perfectly ok yesterday, and today be broken in subtle ways, and
> this wouldn't alter the gcc releasing schedule.

I understand. On would wish that we (the Ada community, if I'm still
allowed to include myself here) could develop enough influence to
change that.

> It's for this reason, coupled with the fact that AdaCore endorsed versions
> use 3.4.6 as backend and not 4.x, and with the fact that gnat is enduring

3.4 at least still has the Read/Write bug. So even if it might be
better than 4.1. in some respects, it won't solve my problem.

> heavy changes due to the addition of 2005 features, that I hold very low
> expectatives on the gcc-gnat, for the time being.

But I understand what you're saying here. Thanks for the info, my
hopes where actually higher, but I learn to adjust them :-).

> > Let that be a lesson to those that don't hold dear their old compiler
> > versions: Changing to new version will just get you new, different
> > sneaky bugs, not less :-).
> 
> Ah, the times when one never ever ran in a compiler bug...

Turbo Pascal. The only bugs I ever complained to the German Borland
(Heimsoeth) dependence about where my own misconceptions.

Regards -- Markus

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[Ludovic Brenta]

Alex R. Mosteo a écrit :
> Last time I heard, Ada is not a release criterion for gcc. As I understand
> it, this means that the gcc version, even if GMGPL, can be in any state. It
> could be perfectly ok yesterday, and today be broken in subtle ways, and
> this wouldn't alter the gcc releasing schedule.

True, Ada is not a release criterion, but GCC _is_ stable, because
AdaCore still follows the rules of development in GCC. They merge most
of their changes during Stage 1; in Stage 2 and Stage 3, only bug fixes
are accepted into the compiler. So, GCC 4.1 is quite useable and
appropriate for most purposes; Robert Dewar himself confirmed so,
verbally, during FOSDEM.

> It's for this reason, coupled with the fact that AdaCore endorsed versions
> use 3.4.6 as backend and not 4.x, and with the fact that gnat is enduring
> heavy changes due to the addition of 2005 features, that I hold very low
> expectatives on the gcc-gnat, for the time being.

Yes, GNAT Pro and GNAT GPL still use the 3.4.6 backend. There were
glitches in GCC 4.0 due to the introduction of tree-ssa, but these are
now resolved in 4.1.

-- 
Ludovic Brenta.

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[Georg Bauhaus]

On Wed, 2006-06-28 at 01:41 -0700, Ludovic Brenta wrote:
>  So, GCC 4.1 is quite useable and
> appropriate for most purposes; Robert Dewar himself confirmed so,
> verbally, during FOSDEM.

Also that they are looking forward to using the 4 series, IIRC,
as the new compilers have more optimizations.

I know that some compiler makers don't like performance comparisons
other than their own, but anyway, among the qualities of compilers
is the speed of executable code. I know about GNAT and ObjectAda on
Windows. GNAT wins, ObjectAda  is o.K.. Any other estimates for other
compilers?

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[Alex R. Mosteo]

M E Leypold wrote:

> 
> "Alex R. Mosteo" <devnull@mailinator.com> writes:

>> Ah, the times when one never ever ran in a compiler bug...
> 
> Turbo Pascal. The only bugs I ever complained to the German Borland
> (Heimsoeth) dependence about where my own misconceptions.

Exactly the example I had in mind :) Ahh, times of youth always seem
greener...

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[Alex R. Mosteo]

Ludovic Brenta wrote:

> Alex R. Mosteo a �crit :
>> Last time I heard, Ada is not a release criterion for gcc. As I
>> understand it, this means that the gcc version, even if GMGPL, can be in
>> any state. It could be perfectly ok yesterday, and today be broken in
>> subtle ways, and this wouldn't alter the gcc releasing schedule.
> 
> True, Ada is not a release criterion, but GCC _is_ stable, because
> AdaCore still follows the rules of development in GCC. They merge most
> of their changes during Stage 1; in Stage 2 and Stage 3, only bug fixes
> are accepted into the compiler. So, GCC 4.1 is quite useable and
> appropriate for most purposes; Robert Dewar himself confirmed so,
> verbally, during FOSDEM.

I didn't want to sound excessively negative. It's just that they're not
forced like other frontends to correct a bug or regression when release is
nearing. And given the number of bugs I've found in the two latest GAP
releases, that I suppose are packaged when they want, after the testing
they want, I wouldn't hold my breath on the 4.x branch. Admitely I am
heavily experimenting with the 05 features, I can't comment on pure 95 code
stability.

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[Steve Whalen]

M E Leypold wrote:
> ...
> Oh d***. I compile a lot of real live code. So I'm not even sure
> wether my program isn't illegal somwhere but got accepted by
> unjustifiedly by 3.15p.
> ...

I share your dilemma about Ada compilers, so here's a late post with
perhaps an insight into your original bug report.

I too still use GNAT 3.15p and ran your original cut down bug test on
3.15p on both Windows and Linux Debian Sarge.  I got slightly different
results, which may indicate your segfault was really a memory
allocation problem in the 2nd half of the program.

The bug test program on Linux blew up with:

"raised PROGRAM_ERROR : stack overflow (or erroneous memory access)"

which is interesting because my Windows version of your test program
ran "successfully" to completion.  It just ran (quickly through the
"write" phase, then took forever (5+ minutes) on the "read" phase on a
slow (450mhz) computer and used up memory like crazy.  It was using
over 30 megabytes of memory before it finished (I think it started at
less then 1 megabyte).  The output files were identical from all runs.

So maybe 3.15p does NOT actually blow up, so much as abuse memory in
some way that evidences different outcomes depending on the
environment.

Dmitry's idiom may help, but I thought I'd report this, since it looks
to me like there may only be one problem, and that's a memory problem
in the "read" phase that just causes different symptoms.

Steve

Re: Possibly fixed in gcc 4.1.1, but bug box -- Was: Re: A smaller self contained test case ...

[M E Leypold]

"Steve Whalen" <SteveWhalen001@hotmail.com> writes:

> So maybe 3.15p does NOT actually blow up, so much as abuse memory in
> some way that evidences different outcomes depending on the
> environment.

Exactly. I've done experiments when the finalizers and initializers in
the variant parts run (by defining a controlled type and writing "Hi,
I'am Finalizer A" to standard output) and it seems to depend on the
phase of the moon which finalizers are run:

 - Sometimes no initializers / finalizers are run during read.

 - Sometimes finalizers are run that shouldn't (finalizers on both
   variant parts are run)

 - Sometimes simply the wrong finalizers are run (I observed that on
   block exit)


The dependency is on the whole circumstances surrounding a call to
read or the exact layout of the record structure. Once compiled,
everything is absolutely repeatably, but adding dummy fields and
changing procedure call sequences, even inserting additional
statements somewhere around the call to read seems to change something
sometimes.

The best thing I had, was that when printing the discriminant after
input it was some value X which should have resulted in the finalizer
of some variant part B being run. Input was completely OK from that
point of view. But on leaving the block, the finalizer for the other
part A was run. Of course if B does now contain a bit pattern which is
not a pointer to some block on the heap and the finalizer to A does
try to deallocate that as a pointer things start disintegrate.

(And since with libc malloc you can often AFAIR free invalid pointers
which is OK for some time but introduces a defect in the heap
managament structures, the symptoms will perhaps only turn up muuuuch
later when on tries to malloc() something different elsewhere.)

I suspected (and still suspect) some problem with the analysis of the
flow of values during code generation. In the last case the old value
of the discriminant would be cached somewhere and used to determine
the action (finalizer to be run) on block exit.

I admit on reading tea leaves here since I'm not really an expert on
this issues. I'd tried to turn optimization of, hoping that would
somehow since it would change optimization: It didn't.

It would certainly be instructive to examine the generated code and
see where the corruption occurs (I also wouldn't completely exclude
the possibily that this is just a memory problem, as you said, perhaps
even in the libc or the way the libc works with the Gnat runtime,
signals and tasking: For all I know it could be race condition in libc
malloc()). I'll postpone that for a while, since understanding this
won't fix it and other priorities are higher now.

Still wanted to record my thoughts on that issue.

> Dmitry's idiom may help, but I thought I'd report this, since it looks

Unfortunately it doesn't. Not in the big picture. It just seems to
happen to suppress illegal invocation of some finalizers in the test
cases, so everything seems to be fine, but with another and more
complicated record layout the error comes back.

It's really a Heisenbug. :-).

> to me like there may only be one problem, and that's a memory problem
> in the "read" phase that just causes different symptoms.

Since I tracked which finalizers are run (or at least tried) my
suspicion is, that it is a memory problem caused by running the wrong
finalizer at the wrong time.

Regards -- Markus