[Bf-python] data corruption
Ken Hughes
khughes at pacific.edu
Thu Nov 17 18:18:51 CET 2005
Toni Alatalo wrote:
> On Thursday 17 November 2005 13:51, Toni Alatalo wrote:
>
>>.. well that seems to be the same in the versions from 2 months ago too, i
>>could not find any changes here in the recent commits
>
>
> went through the changes in Object.c since alpha2 (after confirming the
> problem is not there, thank god!) and did not see anything that could cause
> that.
>
> Ton is coming here soon so i'll ask him if something has related in the
> internals that causes this.
>
> also tested that getting the same selected object (the default cube in the
> default b.blend) with Object.Get('Cube') does not mess the count up, so it is
> really just a GetSelected() issue.
We tracked the bug problem down to a recent commit to Object.c which was
decrementing id.us in Object_dealloc(). Some, but not all, of the
PyObject_NEW() calls to create BPy Objects were incrementing id.us.
GetSelected() was not one of them.
I recall seeing a discussion in IRC related to this. I think the idea
was that since objects and scenes are the two things in Blender which
are deleted when their usage count reaches zero, this caused corruption
if the UI deleted an object Python was wrapping. This patch appears to
let Python keep its own reference to the object so that Blender doesn't
destroy it.
Toni and Ton discussed this and didn't see anything wrong with doing it,
and agreed we should just make sure it's done when every object is
wrapped. I consolidated the various PyObject_NEW() calls to all use
Object_CreatePyObject().
Our question to you: is this the intention of this patch? If so, is
there a better way to do it?
Ken
More information about the Bf-python
mailing list