Am 22.04.2021 um 17:52 schrieb Ryan Joseph via fpc-devel:
On Apr 16, 2021, at 11:35 AM, Ryan Joseph <generic...@gmail.com> wrote:
Got this all integrated and put up the changes to
https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
final review. :)
The next thing to do now is to handle a memory leak. From the bug tracker:
You essentially need to make sure the symbols become part of the specialization
that is picked in the end (cause you create the symbols in make_param_list only
once, but you might use them for multiple generic overloads of which at most
one will be picked).
What you might be able to do is the following (have not looked at it in detail
yet):
- those symbols you directly add to genericparams you ensure that their owner
is the specialization right away (after generate_specialization_phase1)
- those symbols you add to callerparams you'll probably have to bubble up to
htypechk and have that somehow add these syms to the final specialization if it
is picked and free them otherwise
My response:
I looked at this again and it looks like there is just one place where we can
leak memory now and that's those lines from create_unamed_typesym.
newtype:=ctypesym.create(def.typename,def);
newtype.owner:=def.owner;
I set the owner of the new typesym to the target def but what does that even
do? I think you're saying I need to set the owner of that symbol to be a
procdef but I don't see how the helps the memory get freed. I would think when
the specialization is freed we could check some flag in the generic params and
if they are not owned then we free them then.
And with that I'm stuck. :) I don't know how the symbols in the compiler are memory
managed but I don't see setting their owner is helping them get freed. I've tried setting
their owner to the procdef.owner being specialized but that does't do anything either. I
guess I don't understand what adding them to "the final specialization" means
so please clarify.
My naive assumption would be to add them to a list in tspecializationcontext
and free them when the content is freed because I don't think the symbols are
used after the implicit specialization is finished and a proc def is produced,
but I may be wrong about that.
You need to use ChangeOwner as well, but as I wrote you need to pay
attention for which created symbol you do it at what time.
The ones you create in is_possible_specialization you need to add to the
specialization you do in the following generate_implicit_specialization
as those are only created for that specific specialization (though you
also need to free it if you leave is_possible_specialization with False
which you currently don't do).
The ones you create in make_param_list you need to pass back to htypechk
so that they can either be added to the final specialization (if
selected out of multiple ones) or to be freed if none of the ones
created by that invocation to try_implicit_specialization is picked.
That is because they would be shared by all the specializations.
Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
