> 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
I am realizing that this is also a problem. I was creating a memory
leak by having both the subclass and superclass do allocations in
their own __cinit__. The trick you propose:
cdef class Foo:
cdef __cinit__(self):
self._actual_cinit(self)
cdef _actual_cinit(self):
foo_ptr = doTheAllocation()
cdef class Bar(Foo):
cdef _actual_cinit(self):
bar_ptr = doTheAllocation()
When I try this pattern Foo's _actual_cinit *always gets called.* I
looked at the generated C code and it look like this:
__pyx_1 = ((struct __pyx_vtabstruct_6txbase_Foo *)((struct
__pyx_obj_6txbase_Foo *)__pyx_v_self)->__pyx_vtab)->_actualCinit()
When I made _actualCinit(), I got an attribute error (which makes
sense as the Python side of the class has not been built yet.)
Why is the vtable not finding the right _actualCinit implementation?
Is this a bug, or is this to be expected because the class has not
been fully built.
Also, why can't I just do the allocations in the __init__ method?
That has a much more flexible and explicit approach when dealing with
subclasses.
Thanks
Brian
>
>
>
> >
> > 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
>
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
