[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/python BPY_interface.c blender/source/blender/python/api2_2xBone.c

Joseph Gilbert bf-committers@blender.org
Wed, 5 May 2004 07:41:44 -0400


  I have been working on a fix for this since before the release. I am close
to done. Removing the MEM_free block will not fix the problem. In fact it
will make it worse because memory blocks will not be freed now upon exit of
blender. Anyone running a script that creates BPY_Bones and doens't call
Armature.addBone() on them will see a list of unfreed memory upon exit now.
  The fix for this requires a fundemental change in the BPY_Bone struct and
how it's handled. When Bones and armatures were unlinkable this wasn't a
problem. Now it is. The Bone's data doesn't have a Global->main list to keep
track of it. It needs to be freed in the armature list. So if the user
creates a PyBone and doesn't link it the data needs to be freed manually. If
you do link it the data needs to be freed in the G->main->armature list and
not in python. Willian solved this problem by making the verts and faces in
an NMesh PyObject's and then have the user call NMesh.update() to update the
underlying C data. What I'm playing with is an 'internal' Armature.update()
that will update the Bone C struct data upon adding the bone to the
arnature.
  Your right in that the MEM_free has to go. However, in it's current
implementation this will cause memory leaks if removed.

-----Original Message-----
From: bf-committers-admin@blender.org
[mailto:bf-committers-admin@blender.org]On Behalf Of Stephen Swaney
Sent: Wednesday, May 05, 2004 12:33 AM
To: bf-committers@blender.org
Subject: [Bf-committers] Re: [Bf-blender-cvs] CVS commit:
blender/source/blender/python BPY_interface.c
blender/source/blender/python/api2_2xBone.c


Daniel Dunbar wrote:
>
> zuster (Daniel Dunbar) 2004/05/05 05:22:22 CEST
>
>   Modified files:
>     blender/source/blender/python BPY_interface.c
>     blender/source/blender/python/api2_2x Bone.c
>
>   Log:
>    - PyInt_AsLong() was called on a possibly NULL object, this may be
>       a checked error but is no good anyway

After looking at the actual Python sources, the code you replaced
here does exactly the same thing as your changes.  Your version
is more obvious, but the result appears to be identical.
Py_XDECREF() decremetents the refcount of a possibly null object.

>    - Bone_dealloc free'd Blender's actual copy of the Bone! AGH!!!!

This one is definitely ++ungood.  Not nice to mess with
Blender's memory.

>    - On syntax errors the python global dictionary was being free'd
>       twice. AGH!!! again

The dictionary gets released in both branches of the if clause.
The line you removed zeroed out the pointer to the no longer used
python object that gets created when a script is run again.

Or so it all appears to me!

--
Stephen Swaney
sswaney@swbell.net
_______________________________________________
Bf-committers mailing list
Bf-committers@blender.org
http://www.blender.org/mailman/listinfo/bf-committers