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

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

"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