Am 22.04.2021 um 17:52 schrieb Ryan Joseph via fpc-devel:

On Apr 16, 2021, at 11:35 AM, Ryan Joseph <> wrote:

Got this all integrated and put up the changes to 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 
- 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.


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.

fpc-devel maillist  -

Reply via email to