Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2019-12

Memory leak @ tobjectdef.getcopy

6 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Unknown author

1) Maybe it was not always the case, but tobjectdef.vmtentries is never nil (initialised to an empty list @ .create & @ .ppuload. With the following two exceptions, there are no other assigned(vmtentries) checks before dereferencing. I propose that these two useless checks be removed.

@ TVMTWriter.writevirtualmethod :

if not assigned(_class.VMTEntries) then // <-- 1) USELESS: ALWAYS FALSE exit;> for i:=0 to _class.VMTEntries.Count-1 do

@ tobjectdef.getcopy :

Show quoted text 5 lines
if assigned(vmtentries) then // <-- 1) USELESS: ALWAYS TRUE begin tobjectdef(result).vmtentries:=TFPList.Create; // <-- 2) MEMORY LEAK tobjectdef(result).copyvmtentries(self); end;

2) More importantly, the above snipped leaks an empty TFPList when non-nil result.vmtentries is overwritten.

3) Bonus: @ tobjectdef.destroy : under "if assigned(vmtentries)", using vmtentries.free instead of .Destroy makes no sense.

The attached patch remedies all the above.

βþ
Unknown author
to Unknown author
With the following two exceptions, there are no other assigned(vmtentries) checks before dereferencing.

And one assertion @ TVMTBuilder.generate_vmt :

Show quoted text 6 lines
if assigned(_class.childof) then begin if not assigned(_class.childof.vmtentries) then internalerror(200810281); _class.copyvmtentries(_class.childof); end;

Patch is amended.
(Originally, that was a part of another changeset, but I reckon it makes more sense here.)

βþ
Ryan Joseph
to Unknown author: 1) Maybe it was not always the case, but tobjectdef.vmtentries is never nil (initialised…

Blaise how are the closures coming? I think you have enough done you could submit it into trunk so we can start testing. Please if you can get to this we have people willing to help. It's been some 6 months now since I offered to help and it's still in limbo. Sorry to pester you but we're really anxious to get this integrated already. :)

Regards,
Ryan Joseph

Unknown author
to Ryan Joseph
Ryan Joseph wrote
how are the closures coming?

You are literally looking at them coming.

you could submit it into trunk

That is exactly what I am doing. In small self-contained reviewable changesets.

It's been some 6 months now

My last submission in August got no replies, and I took a break for other stuff. I have resubmitted it yesterday, and things seem to be going. Let us hope for a steady flow.

βþ
Sven Barth
to Ryan Joseph: Blaise how are the closures coming? I think you have enough done you could submit it into…

Ryan Joseph via fpc-devel schrieb am So.,
1. Dez. 2019, 19:06:

Show quoted text 6 lines
Blaise how are the closures coming? I think you have enough done you could submit it into trunk so we can start testing. Please if you can get to this we have people willing to help. It's been some 6 months now since I offered to help and it's still in limbo. Sorry to pester you but we're really anxious to get this integrated already. :)

I don't know how far Blaise has come regarding the points I had mentioned to him way back and that he pushed back until it was time for reintegration. If he hasn't yet found the time to tackle them, then the whole feature isn't even remotely ready to be reintegrated. But we'll probably see that soon...

Regards,
Sven

Sven Barth
to Unknown author: And one assertion @ TVMTBuilder.generate_vmt : Patch is amended. (Originally, that was a…

Am 01.12.2019 um 18:08 schrieb

Show quoted text 16 lines
On 01.12.2019 19:15, wrote: > With the following two exceptions, there are no other > assigned(vmtentries) checks before dereferencing. And one assertion @ TVMTBuilder.generate_vmt : >     if assigned(_class.childof) then >       begin >         if not assigned(_class.childof.vmtentries) then >           internalerror(200810281); >         _class.copyvmtentries(_class.childof); >       end; Patch is amended. (Originally, that was a part of another changeset, but I reckon it makes more sense here.)

Applied in r43626 with the exception of the change from vmtentries.Free to vmtentries.Destroy. Modus operandi inside the compiler is to use .Free, not .Destroy (I know, there are a few exceptions, but that doesn't change the modus operandi).

It would be up to the compiler's optimizations that it can lower the .Free to .Destroy (it currently probably won't, but it shouldn't be /impossible/ to do).

Regards,
Sven