Seg fault when exiting

[GoogleCodeExporter]

I get a seg fault when exiting a program that uses visvis.  This happens with 
the simple examples, the embedding examples, and ipython.  The guilty commit 
seems to be d007363b922a.  Unfortunately, there's a lot that changed there, so 
it's not immediately obvious what the problem is.

Here's a sample backtrace.  I have the Python debug symbols installed, but it's 
not giving a lot of detail.
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff06aac86 in FT_Done_FreeType ()
   from /usr/lib/x86_64-linux-gnu/libfreetype.so.6
#2  0x00007ffff33c3ea4 in ffi_call_unix64 ()
   from /usr/lib/python2.7/lib-dynload/_ctypes.so
#3  0x00007ffff33c38c5 in ffi_call ()
   from /usr/lib/python2.7/lib-dynload/_ctypes.so
#4  0x00007ffff33b42c2 in _ctypes_callproc ()
   from /usr/lib/python2.7/lib-dynload/_ctypes.so
#5  0x00007ffff33b4aa2 in PyCFuncPtr_call.2798 ()
   from /usr/lib/python2.7/lib-dynload/_ctypes.so
#6  0x00000000004c7c76 in PyObject_Call ()
#7  0x000000000042aa4a in PyEval_EvalFrameEx ()
#8  0x000000000042abe2 in PyEval_EvalFrameEx ()
#9  0x00000000004317f2 in PyEval_EvalCodeEx ()
#10 0x000000000054aa40 in function_call ()
#11 0x00000000004c7c76 in PyObject_Call ()
#12 0x000000000049e9ba in instancemethod_call.8548 ()
#13 0x00000000004c7c76 in PyObject_Call ()
#14 0x00000000004c7d36 in PyEval_CallObjectWithKeywords ()
#15 0x0000000000441015 in slot_tp_del.25361 ()
#16 0x0000000000444c6e in subtype_dealloc.25364 ()
#17 0x0000000000505665 in insertdict.18180 ()
#18 0x000000000054d989 in PyDict_SetItem ()
#19 0x000000000049a439 in _PyModule_Clear ()
#20 0x000000000048dbc9 in PyImport_Cleanup ()
#21 0x0000000000482b8b in Py_Finalize ()
#22 0x000000000054c45a in Py_Main ()
#23 0x00007ffff68e576d in __libc_start_main ()
   from /lib/x86_64-linux-gnu/libc.so.6
#24 0x000000000041b931 in _start ()

Original issue reported on code.google.com by rschr...@gmail.com on 2 Aug 2012 at 2:11

[GoogleCodeExporter]

Since the problem seems to be in FT_Done_FreeType, I started to look for that.  
It's called in the destructor, which we attach manually.  Revision d007363b922a 
changed this from being done directly on the library to being handled by the 
wrapper.  My bet is that things aren't being destroyed in the expected order, 
and this is somehow causing the seg fault.  (In my limited experience with 
Python destructors, they're never called when I expect them to be.)

Reverting that bit of code back to something more like the previous version 
fixes the problem for me.  I've attached a patch.  I really don't know what I'm 
doing here, so I'd like you to take a look over it before I push.

Original comment by rschr...@gmail.com on 2 Aug 2012 at 2:59

• Changed state: Started

Attachments:

• freetype.patch

[GoogleCodeExporter]

I hadnt tested on Linux yet. I get a segfault too. I dove into this a bit 
deeper and tried a couple of different approaches to do the FT_Done_FreeType 
call.

I'm a bit confused, because I know think that with the non-segfaulting 
appraches, it is simply never called. I tested this by creating a dummy file in 
the destructor, but you can also see this from the code:

def __del_library__(self):
    global __handle__
    if __handle__:
        try:
            FT_Done_FreeType(byref(self))
            __handle__ = None
        except:
            pass
FT_Library.__del__ = __del_library__

__handle__ is the singleton instance of FT_Library. The __del__ can never 
execute, because it needs a reference to __handle__, which is ... the object 
that we want to destroy itself! 

Arg! But not-calling FT_Done_FreeType seems wrong too...

Original comment by almar.klein@gmail.com on 2 Aug 2012 at 8:31

[GoogleCodeExporter]

I phrased that wrong. The __del__ *can* execute, but in that case __handle__ 
will already have been set to None by the Python cleanup thingy.

In some other approaches it seems that the __del__ is simply never executed 
though.

Original comment by almar.klein@gmail.com on 2 Aug 2012 at 8:36

[GoogleCodeExporter]

Found it. It should be "self._dll.FT_Done_FreeType(self._handle)"
not "self._dll.FT_Done_FreeType( byref(self._handle) )"

Will notify Nicolas about this bug.

Original comment by almar.klein@gmail.com on 2 Aug 2012 at 9:06

[GoogleCodeExporter]

This issue was closed by revision dd74eba20b41.

Original comment by almar.klein@gmail.com on 2 Aug 2012 at 9:06

• Changed state: Fixed