You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There has been some hints that the current implementation may have memory leaks and that FT_Done_* is not always called as expected. Related issues include #44 and #169, and the discussion in the pull request #171.
Calling it a memory leak is not entirely correct. It is rather than freetype-py did not automatically tidy things up in the right order. So if you have python destructors automatically calling the destructors in c for you, then you may have segfaults when python does not destroy them in the right order; the "fix" at some point in the past was to NOT automatically call c desctructors from python instructors, and just not tidy up at all, and rely on the OS to tidy up on exit of the python script. If you are familiar with freetype enough, you can manually calls the c destructors from freetype-py in the right order within, for long-running freetype-py scripts.
I think it may be a little too much bending over for users' convenience to have automatic tidy up that "works". The c-side is basically library have faces, faces have glyphs, glyphs have bitmaps and outlines, etc. And each of those have "up" references and know what they belong. C users always creates in one direction of order and destroy it from the opposite order.
If you want convenient automatic tidy up to work I.e. you use a whole bunch of faces, find a whole bunch of glyphs, draw a whole bunch of outlines and bitmaps, and then just move on, and hope that freetype-py to tidy them up for you, there will be a whole lot of code on the python side tracking what owns what and what references what. Like if you destroy a face, do you destroy all its associated glyphs and bitmaps now, or do some lazy thing and marked it as deleted but not, and wait until the last glyph/bitmap's with this face is destroyed before actually destroying the face?
There has been some hints that the current implementation may have memory leaks and that
FT_Done_*
is not always called as expected. Related issues include #44 and #169, and the discussion in the pull request #171.The core of issue on exit, freetype/__init__.py", line 1233, in __del__ TypeError: 'NoneType' object is not callable #169 and another described in the comments of access violation writing error in Face.__del__() #44 is what happens during interpreter shutdown, namely that we can't rely on the
FT_Done_*
functions to exist at that step. This was fixed forFace
in pull request freetype.Face.__del__: check first if FT_Face_Done has been set to None (#169) #171. However, I think we're making the same mistake inGlyph.__del__
andStroker.__del__
. I can prepare a PR for this.The issue access violation writing error in Face.__del__() #44 and some of the comments in issue on exit, freetype/__init__.py", line 1233, in __del__ TypeError: 'NoneType' object is not callable #169 and PR freetype.Face.__del__: check first if FT_Face_Done has been set to None (#169) #171 seem to hint to some memory leaks but it's not clear to me how to reproduce it.
The text was updated successfully, but these errors were encountered: