[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