Hi Jerry,
thanks for the review and the kind words. Committed as gcc-15-8481-g0f344846a62
Thanks again,
Andre
On Thu, 20 Mar 2025 11:42:35 -0700
Jerry D <jvdelis...@gmail.com> wrote:
> On 3/20/25 9:20 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > attached patch fixes a 15-regression where an element of an actual
> > temporary array, i.e., elemental([ e1, e2...]) passed to the formal
> > polymorphic dummy leads to a double free of the derived types components.
> > This patch prevents this by preventing the deallocation of the array
> > constructors temporary, when the formal is polymorphic. ...
> >
> > Folks its so hard to explain this in prose. I rewrote above paragraph the
> > third time now. And I still don't understand on re-reading. So here is some
> > pseudo code:
> >
> > struct derived {
> > char *c; // This is the component suffering from double-free
> > };
> >
> > derived[2] atmp = [ derived(""), derived("")]
> >
> > forall a in atmp
> > derived t_a = a; // <- Copy of a, but no deep copy, i.e. t_a.c == a.c
> > class_temp = class_derived(a); // set _vtype left out for brevity
> > call elemental_function(class_temp);
> > if (class_temp._data.c != NULL)
> > free(class_temp._data.c); // and set it to NULL
> > if (t_a.c != NULL)
> > free(t_a.c); // BOOM, this is freeing the same c
> > end
> >
> > Generating the last if-block and the free is what this patch prevents for
> > polymorphic dummys that stem from an array construction. And only for those.
> >
> > Sorry, I am having a hard time explaining things today. So I hope the code
> > above will do.
> >
> > Regtested ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> OK and thanks for the fix. Your prose is fine and your comment in the
> code suffices.
>
> Thanks for the patch.
>
> Jerry
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
