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

[Daniel Dunbar]

I see, I wondered why it was there in the first place,
but a quick check didn't show anywhere that bones were
actually created. I see now that they are. Not-freeing
memory is of course still better than free'ng memory
that is still used.

I don't think you need an update procedure, just set
a flag in the Bone structure that indicates if the
PyBone *owns* the bone, and it should be free'd on
exit, or if the PyBone just got the reference to the
bone from an already existing Bone. When the PyBone
gets addBone'd to an armature, unset the flag.

--- Joseph Gilbert <models@paposo.com> wrote:
>   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
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers


=====
daniel dunbar
daniel@zuster.org