On Apr 18, 2008, at 3:56 PM, Brian Granger wrote:

> OK, I still haven't run valgrind (still compiling the c++ library on
> Linux) but I have used gdb to figure out more of what is going on.
> This leads me to a more general question about __cinit__ and
> __dealloc__:
>
> I have 2 c++ class that one of which is a subclass of the other.  I am
> mirroring this hierarchy in cython by creating two cdef'd classes:
>
> cdef class Foo:
>
>   cdef Foo_c *foo_ptr
>
>   def __dealloc__(self):
>     functionThatCallsDelete(self.foo_ptr)
>
> cdef class Bar(Foo):
>
>   cdef Bar_c *bar_ptr
>
>   def __cinit__(self):
>     self.bar_ptr = newBar()
>     self.foo_ptr = <Foo_c *>self.bar_ptr
>
>   def __dealloc__(self):
>     functionThatCallsDelete(self.bar_ptr)
>
> The nice thing about this approach is that all the methods on Foo,
> also appear on Bar, but the pointer type is right.  This (almost)
> makes for a really nice way of having c++ subclasses reflected in
> cython....
>
> But, what I find is that the __dealloc__ method of both Bar and Foo
> are being called.  Because their underlying pointers (bar_ptr and
> foo_ptr) point to the same thing, the second segfaults with a double
> delete problem.  So question:
>
> How do people handle these things in cython?  Can I prevent
> __dealloc__ from being called twice?

No, __dealloc__ is guaranteed to be called, otherwise this could very  
easily lead to memory leaks. I'm no C++ expert, but I'm not  
understanding why __dealloc__ needs to be defined twice. Won't the  
delete that's called on self.foo_ptr delete self.bar_ptr just fine  
(since they're really pointers to the same object?)


If that doesn't work, try

cdef class Foo:
     def __dealloc__(self):
         self._dealloc_cpp_pointers()
     cdef _dealloc_cpp_pointers(self):
         functionThatCallsDelete(self.foo_ptr)
     ...

cdef class Bar(Foo):
     ...
     cdef _dealloc_cpp_pointers(self):
         functionThatCallsDelete(self.bar_ptr)
     ...


>
> Thanks
>
> Brian
>
> On Fri, Apr 18, 2008 at 3:00 PM, Michael.Abshoff
> <[EMAIL PROTECTED]> wrote:
>> Brian Granger wrote:
>>
>>  Hi Brian,
>>
>>
>>>>  Yes, at least to see if it can spot the problem.
>>>>
>>>>  To get started: Build your own python. Make sure to compile it  
>>>> with
>>>>  "--without-pymalloc" and also set the compile flags to "-O0 - 
>>>> g". Build
>>>>  valgrind 3.3.0 [or install it from binary packages] and run  
>>>> your code
>>>>  under it. If it segfaults valgrind [it happens to me somewhat  
>>>> regularly,
>>>>  but then usually something evil is happening in libSingular ;]  
>>>> go and
>>>>  check out the 3.4svn version.
>>>
>>> Thanks, I will try this out.  I have never used valgrind, so this is
>>> very helpful.
>>
>>  Ok, to run it do
>>
>>  valgrind --tool=memcheck --trace-children=yes --leak-resolution=high
>>  --log-file=foo ./path/to/python
>>
>>  Then do your thing, quit python. At that point there should be  
>> foo.$PID
>>  in the cwd. For a C++ specific example where we did dumb things at
>>  dealloc time from Sage look at
>>
>>  http://trac.sagemath.org/sage_trac/ticket/1573
>>
>>  Also: searching for delete[] in Sage's trac will turn up a number of
>>  other examples. If you get stuck feel free to post the example  
>> here and
>>  once I take a look at the code I may be able to help you out.
>>
>>
>>>>  Let me know if you have any trouble.
>>>
>>> Thanks
>>>
>>> Brian
>>>
>>
>>  In the end I would assume people won't mind if some easy cases  
>> would get
>>  added to the Cython wiki in form of a tutorial, i.e. if you do  
>> FOO it
>>  blows up but BAR fixes it. I have meant to do this for a long,  
>> long time
>>  in the Sage wiki, but never got around to it. But it should  
>> probably be
>>  in the Cython wiki for obvious reasons.
>>
>>  Thought?
>>
>>
>>
>>  Cheers,
>>
>>  Michael
>>  _______________________________________________
>>  Cython-dev mailing list
>>  [email protected]
>>  http://codespeak.net/mailman/listinfo/cython-dev
>>
> _______________________________________________
> Cython-dev mailing list
> [email protected]
> http://codespeak.net/mailman/listinfo/cython-dev

_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to