On Apr 18, 2008, at 4:39 PM, Brian Granger wrote: >> 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?) > > Yes. > >> cdef class Foo: >> def __dealloc__(self): >> self._dealloc_cpp_pointers() >> cdef dealloc(self): >> >> functionThatCallsDelete(self.foo_ptr) >> ... >> >> cdef class Bar(Foo): >> ... >> cdef _dealloc_cpp_pointers(self): >> functionThatCallsDelete(self.bar_ptr) >> ... > > Will the method lookup for self._dealloc_cpp_pointers actually find > the one in the right class though? I would think that in class Foo, > self is known to be a Foo, therefore Foo._dealloc_cpp_pointers() will > always be called? I will try this, but maybe it would work if the > method were not cdefd. Also, will this type of thing work with > __cinit__?
No, inheritance for _dealloc_cpp_pointers would work just like in Python (though if it's a cdef or cpdef method it uses vtables rather than dictionaries). The only methods that do not get overridden are __cinit__ and __dealloc__, and this is because we need to guarantee that these methods get called, no matter what subclasses do. __cinit__ is guaranteed to be called *exactly* once for an object, and if successful __dealloc__ will be called *exactly* once on deallocation. This makes these two methods ideal places to do memory management associated with an object. - Robert > > Thanks > > Brian > >> >> >> >>> >>> 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 >> > _______________________________________________ > 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
