[Bf-python] data corruption

[Gilbert, Joseph T.]

Lol first of all this was part of my commit and it was not intended.
This was stuff I was screwing around with and it ended up in the
armature commit!

I don't know how or when objects and scenes are free'd but object.c used
to have this line (before I screwed it up):

object->id.us = 0;

So it can't be completely automatic. There must be a trigger somewhere
that tests the id.us for these 2 objects and removes them (maybe a
manual delete or something).

I also think it makes sense to add python as a user for ID's (y not?),
however, it may cause more harm than good if python exits erratically
and data is not free'd properly on exit.

-----Original Message-----
From: bf-python-bounces at projects.blender.org
[mailto:bf-python-bounces at projects.blender.org] On Behalf Of Martin
Poirier
Sent: Thursday, November 17, 2005 12:50 PM
To: Blender Foundation Python list
Subject: RE: [Bf-python] data corruption



--- "Gilbert, Joseph T." <jgilbert at tigr.ORG> wrote:

> I am not sure if objects behave the same way as
> other data. If an
> armature data block has an id.us of 0 it's not freed
> (because we set it
> to zero manually when the object is created). Maybe
> what's happening is
> that when a user manually deletes an object from a
> scene somewhere the
> free() code for that object is called?

Ken mentionned that in his previous mail, Objects and
Scenes are the only two blender types which are
automaticly freed from memory when their user count
reaches zero.

For all the others, BPY wouldn't *need* to increase
the users on binding and decrease on destroy, but it
would be safer nonetheless to do it, I think.

Martin


		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
_______________________________________________
Bf-python mailing list
Bf-python at projects.blender.org
http://projects.blender.org/mailman/listinfo/bf-python