The python API has a number of crash scenarios that would be time consuming to systematically fix. If you close() a font at the python level there can still be any number of fontforge.glyph objects (for example) that, if subsequently used, will cause crashes. This isn't great, but because such scenarios are rare and avoidable it isn't the end of the world.
Unfortunately PyFF_GlyphPen_dealloc() has the following code:
static void PyFF_GlyphPen_dealloc(PyFF_GlyphPen *self) {
if ( self->sc!=NULL ) {
if ( self->changed )
SCCharChangedUpdate(self->sc,self->layer);
self->sc = NULL;
}
Py_TYPE(self)->tp_free((PyObject *) self);
}
Changed is set to True by almost every operation and never set back to False.
I think the idea here is to avoid calling SCCharChangedUpdate() after every change for performance reasons and therefore to do it on deallocation as an alternative. That's not great because the pen might hang around because there's still a reference to it, but maybe it's acceptable. Unfortunately it means a GlyphPen dangling after a font is closed (or, presumably, after the underlying SplineChar is deleted) will call SCCharChangedUpdate() on freed memory even when it is never used again.
The proper fix for these problems would be to keep lists of python objects with their respective objects and "invalidate" them as needed. Short of that I'm not sure what to do about this problem. One option is to add a "delay update" parameter to each pen method and call SCCharChangedUpdate() when it isn't specified. Then folks who don't want to pay the performance penalty could add the parameter and everyone else could just live with it.
The python API has a number of crash scenarios that would be time consuming to systematically fix. If you
close()a font at the python level there can still be any number offontforge.glyphobjects (for example) that, if subsequently used, will cause crashes. This isn't great, but because such scenarios are rare and avoidable it isn't the end of the world.Unfortunately
PyFF_GlyphPen_dealloc()has the following code:Changed is set to
Trueby almost every operation and never set back toFalse.I think the idea here is to avoid calling
SCCharChangedUpdate()after every change for performance reasons and therefore to do it on deallocation as an alternative. That's not great because the pen might hang around because there's still a reference to it, but maybe it's acceptable. Unfortunately it means a GlyphPen dangling after a font is closed (or, presumably, after the underlyingSplineCharis deleted) will callSCCharChangedUpdate()on freed memory even when it is never used again.The proper fix for these problems would be to keep lists of python objects with their respective objects and "invalidate" them as needed. Short of that I'm not sure what to do about this problem. One option is to add a "delay update" parameter to each pen method and call
SCCharChangedUpdate()when it isn't specified. Then folks who don't want to pay the performance penalty could add the parameter and everyone else could just live with it.