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

[Joseph Gilbert]

Yes, i agree. The BPy_Bone should have a flag telling whether or not it is
armature linked. However, Bone.New() should not allocate the memory for the
Bone struct. Otherwise it must be freed on exit (because blender doesn't
keep track of this data normally). Armature.addBone() should allocate the
Bone struct and then link it to the armature. So what needs to happen is
that python vars should handle the data until the bones become armature
linked - (at which time the BPy_Bone should then access the underlying Bone
struct and not it's python vars for it's internal methods). When the Bone
struct is created and armature linked, an internal method needs to update
the Bone struct from the BPy_Bone python vars. When the BPy_Bone is freed no
memory was allocated for it using this scenario and therefore if the bone
was armature linked the G.main->armature list will free it, otherwise python
will free the python vars. When lists are returned such as
Armature.getBones() the BPy_Bone will contain a &reference to the Bone
struct, and when the list of BPy_Bone's are freed the Bone struct stays
intact. This hopefully should solve the problem. :|

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


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