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