[cairo] Fw: bitrot of the python freetype example

Fri Apr 21 16:41:06 UTC 2017

Reposting after subscribing. The fix ( https://lists.cairographics.org/archives/cairo/2017-April/028026.html ) works; but I'd like to get the discussion going on getting the example better, perhaps. Afterall, this is mostly decade-old code from 2007, and freetype-py has been around for 6 years.

I am glad to see that pycairo is finally moving forward, also coincidentally this month...

--- On Tue, 18/4/17, Hin-Tak Leung <htl10 at users.sourceforge.net> wrote:

> From: Hin-Tak Leung <htl10 at users.sourceforge.net>
> Subject: bitrot of the python freetype example
> To: ldo at geek-central.gen.nz, cairo at cairographics.org
> Date: Tuesday, 18 April, 2017, 20:56

https://cairographics.org/cookbook/freetypepython/

The current segfault seems to be in the section of code which was added Lawrence D'Oliveiro
( https://lists.cairographics.org/archives/cairo/2015-December/026942.html ) just over a year ago, supposedly to do with memory leaks:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f5a9ffc86c5 in _cairo_user_data_array_get_data () from /lib64/libcairo.so.2
(gdb) bt
#0  0x00007f5a9ffc86c5 in _cairo_user_data_array_get_data () from /lib64/libcairo.so.2
#1  0x00007f5aa0707c58 in ffi_call_unix64 () from /lib64/libffi.so.6
#2  0x00007f5aa07076ba in ffi_call () from /lib64/libffi.so.6
#3  0x00007f5aa0960eaf in _ctypes_callproc () from /usr/lib64/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so
#4  0x00007f5aa095b0da in PyCFuncPtr_call () from /usr/lib64/python3.5/lib-dynload/_ctypes.cpython-35m-x86_64-linux-gnu.so
#5  0x00007f5aa86a6167 in PyObject_Call () from /lib64/libpython3.5m.so.1.0
#6  0x00007f5aa87625ea in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0
#7  0x00007f5aa87679b3 in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0
#8  0x00007f5aa87640d9 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0
#9  0x00007f5aa87679b3 in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0
#10 0x00007f5aa8767a93 in PyEval_EvalCodeEx () from /lib64/libpython3.5m.so.1.0
#11 0x00007f5aa8767abb in PyEval_EvalCode () from /lib64/libpython3.5m.so.1.0
#12 0x00007f5aa8786d44 in run_mod () from /lib64/libpython3.5m.so.1.0
#13 0x00007f5aa8789295 in PyRun_FileExFlags () from /lib64/libpython3.5m.so.1.0
#14 0x00007f5aa8789404 in PyRun_SimpleFileExFlags () from /lib64/libpython3.5m.so.1.0
#15 0x00007f5aa87a006c in Py_Main () from /lib64/libpython3.5m.so.1.0
#16 0x0000561470910b60 in main ()
(gdb)

If I comment out the section added by Lawrence D'Oliveiro, (the whole "if _cairo_so.cairo_font_face_get_user_data ... #endif" clause), then it sgefault inside
freetype, which is a bit more promising:

(gdb) bt
#0  0x00007f4d9ce04bcf in FT_Set_Transform () from /lib64/libfreetype.so.6
#1  0x00007f4d9d659585 in _cairo_ft_unscaled_font_set_scale () from /lib64/libcairo.so.2
#2  0x00007f4d9d65cda3 in _cairo_ft_font_face_scaled_font_create () from /lib64/libcairo.so.2
#3  0x00007f4d9d5f9b24 in cairo_scaled_font_create () from /lib64/libcairo.so.2
#4  0x00007f4d9d5bfeeb in _cairo_gstate_ensure_scaled_font () from /lib64/libcairo.so.2
#5  0x00007f4d9d5c2e71 in _cairo_gstate_get_scaled_font () from /lib64/libcairo.so.2
#6  0x00007f4d9d5bb2f0 in _cairo_default_context_get_scaled_font () from /lib64/libcairo.so.2
#7  0x00007f4d9d5b5453 in cairo_show_text () from /lib64/libcairo.so.2
#8  0x00007f4d9d8c6b5f in pycairo_show_text () from /usr/lib64/python3.5/site-packages/cairo/_cairo.cpython-35m-x86_64-linux-gnu.so
#9  0x00007f4da5ccdee9 in PyCFunction_Call () from /lib64/libpython3.5m.so.1.0
#10 0x00007f4da5d45e50 in PyEval_EvalFrameEx () from /lib64/libpython3.5m.so.1.0
#11 0x00007f4da5d479b3 in _PyEval_EvalCodeWithName () from /lib64/libpython3.5m.so.1.0
#12 0x00007f4da5d47a93 in PyEval_EvalCodeEx () from /lib64/libpython3.5m.so.1.0
#13 0x00007f4da5d47abb in PyEval_EvalCode () from /lib64/libpython3.5m.so.1.0
#14 0x00007f4da5d66d44 in run_mod () from /lib64/libpython3.5m.so.1.0
#15 0x00007f4da5d69295 in PyRun_FileExFlags () from /lib64/libpython3.5m.so.1.0
#16 0x00007f4da5d69404 in PyRun_SimpleFileExFlags () from /lib64/libpython3.5m.so.1.0
#17 0x00007f4da5d8006c in Py_Main () from /lib64/libpython3.5m.so.1.0
#18 0x000055a9e50a3b60 in main ()
(gdb)

Now I have a debug-enabled freetype lying around, so I set LD_LIBRARY_PATH and do the usual, and see that

FT_Open_Face: Requesting face 0
FT_Stream_Open: opened `/usr/share/fonts/dejavu/DejaVuSerif.ttf' (379740 bytes) successfully
TTF driver
  SFNT driver
...

FT_Open_Face: New face object, adding to list
FT_Open_Face: Creating glyph slot
FT_New_GlyphSlot: Creating new slot object
FT_New_GlyphSlot: Return 0x0
FT_Open_Face: Creating size object
FT_Open_Face: Return 0x0
Segmentation fault (core dumped)

So at least FT_Open_Face() is called correctly, but no other calls to FreeType is made after FT_Open_Face()  before  the segfault with FT_Set_Transform(). It seems that cairo/pycairo is possibly calling FT_Set_Transform ()  wrongly?

BTW, it is not exactly clear how to get at the git+ssh://cairographics.org/git/cairo-www via anonymous read-only or browse history online ( https://lists.cairographics.org/archives/cairo/2016-January/027214.html ) Other wise I'd try to get hold of the previous version of the example and give it a try.

And, yes, I am aware of github.com/ldo/qahirah - I just find examples to be few and far between, the coding style a bit weird, and didn't want to spend time on it. (besides, I'd like python2 compatibility) . Alternative with cairoffi I may want to look into.