*** Bug 661471 has been marked as a duplicate of this bug. ***

*** Bug 661470 has been marked as a duplicate of this bug. ***

Are iters actually boxed?  I thought they were structs.

seems so:

from the docs:
  GBoxed
   +----GtkTextIter

Also see http://git.gnome.org/browse/gtk+/tree/gtk/gtktextiter.c#n469

Iters are containers with arbitrary gpointers.  There is no way to support them generically and we can't put a dependency on Gtk.  Someone needs to think deeply about what an iter is and how it can be consistently supported in scripting languages.  Until then setting iters are never going to work.

forgive my ignorance, but I do not understand why iters are different from any other boxed types: in the commit nacho linked in comment #1 the iter is correct before returning from the callee and is corrupted when inspected from the caller.

I would have expected that pygobject figures out it is a boxed type and uses the gboxed copy/free methods to handle it, without having to care what is inside...

The interface is passing the iter in as caller-allocated.  So an iter is passed in that needs to filled in (not assigned).  The problem is that the iter is just a struct of pointers which have no context in GI.  We can not set them because they can't be memory managed.  PyGTK got around this by leaking python objects.  It would set the pointer to the python object and Py_INCREF it with no knowledge of when the iter goes away (most iters are are statically created as a local variable in the calling code).  That isn't to say they can't be supported but someone has to think about the best way to support them in all cases without putting a dependency on Gtk.

One quick thought would be to create a pluggable iter interface in PyGObject which keeps track of the current outstanding iters and the data encapsulated in them.  It would then periodically unref those pieces of data and change the timestamp on the owning model to invalidate the iters.  Since iters are supposed to be short lived within a single scope (they aren't supposed to be stored and reference in a later code block) this should work fine.  It is just a complicated patch that needs someone to work out all of the details.

(In reply to comment #8)
> The interface is passing the iter in as caller-allocated.  So an iter is passed
> in that needs to filled in (not assigned).  The problem is that the iter is
> just a struct of pointers which have no context in GI.  We can not set them
> because they can't be memory managed.

This is the part I do not understand: in this case python does not need to fill the structure itself, python calls a gtk api and the struct is filled by gtk in C

(In reply to comment #9)
> (In reply to comment #8)
> > The interface is passing the iter in as caller-allocated.  So an iter is passed
> > in that needs to filled in (not assigned).  The problem is that the iter is
> > just a struct of pointers which have no context in GI.  We can not set them
> > because they can't be memory managed.
> 
> This is the part I do not understand: in this case python does not need to fill
> the structure itself, python calls a gtk api and the struct is filled by gtk in
> C

Yep that should work fine but inevitably people want to do things like iter = (1,1).  That is where we run into issues.  Theoretically it should work provided we build a framework around iters which explicitly manages their lifecycle by invalidating the model when the wrapped python object is destroyed.

BTW we can't assign pointer fields though as there is little context on what to store in that field.  For instance if you try to assign an integer does that get converted to a pointer?  What about a PyGObject?  Do we get the wrapped pointer oe assign the python pointer for the wrapper itself?

For caller allocates we would have to have a iter_assign method for this to work.

Could someone please provide a minimal test case? Mabye this will help reviving this issue.

hm. I am reopening as I can't see any open non developer question. And I'm setting to NEW as this has been confirmed.

Linked this to a couple tickets:
 https://bugzilla.gnome.org/show_bug.cgi?id=668356
This was a patch that went in to work with gpointers as if they are pointers to python objects which will leak as John describes. 

I recently opened a rant ticket about this here:
 https://bugzilla.gnome.org/show_bug.cgi?id=683599
I think Johns comments are right on. The only thing I think gpointers should ever be interpreted as in pygobject are ints, this at least removes reference leaks and potential crash dangers. It is then left up to the application developer to interpret the int however they like. For instance, using it as an integer key into a pool of properly ref counted python object in the higher level structure that manages the iters.

Can someone provide a way to reproduce this? Minimal code snippet is preferred but just instructions for how to notice this in the gedit plugin would be helpful.

I believe the problem is that GtkTextIter requires using gtk_text_iter_assign() for copying memory. PyGI uses memcopy to overwrite caller allocated out argument memory with the boxed object returned from the Python function (this has always seemed a bit sketchy to me in general).

Possible fixes:

1) Annotate the text iter as an input argument and formalize pass-by-ref semantics for boxed arguments to vfuncs in PyGI. This basically means removing the special casing with pass-by-ref from bug 734465 and using it for any vfunc/callback boxed input arg. And also adding the copy-if-stored hack from bug 736175.

2) Add something like g_boxed_assign() and corresponding callback registration to GLib which would allow generic support for boxed assignment to existing memory. This might also allow us to remove special casing of GValue argument marshaling because the fundamental is GBoxed and could use g_value_copy() as the assign function.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/pygobject/issues/21.