Python lenses segfault with pygobject3

The bug appears to be triggering a segfault inside libdee, so it's probably not libunity as I first thought... One can also reproduce somewhat easier by simply running the Python demo script from lp:dee (http://bazaar.launchpad.net/~unity-team/dee/trunk/view/head:/examples/pythontricks.py)

Or to really make it simple; this python session:

>>> from gi.repository import Dee
>>> m = Dee.SequenceModel.new ()
>>> m.set_schema ("s", "i")
>>> m.append("hello", 27)
Segmentation fault (core dumped)

I dug into this, and these are the findings:

- the GVariant array which is a parameter of append_row() comes garbled from python, it looks like a bug in pygobject
- I talked to John, who said they'll need to special case GVariants like they do GValues, but it's not going in before the freeze

Of course one of the options is also to break the API (use GArray / GPtrArray).

We can't change the Dee ABI at such a fundamental level at this point in the cycle. Even disregarding that I think the Dee API as it is now is totally sensible, it allows for natural stack allocation of the containing array and tricks like that, adding to that that it is totally standard Cism to use arrays like this. In other words: PyGI must be fixed :-) (since it's also a regression)

(I am working on this right now, to follow progress look at the upstream bug report)

*phew* that was harder than I hoped :-) But the upstream bug now contains patches and tests to fix this.

I just ran a check, that the very latest patch set I attached upstream (today) does make the Dee bindings fully functional (again)

I applied the patch, python lenses are back! Thanks Mikkel.

After today updates this bugs seems to have come back. When I run in python

>>> from gi.repository import Dee
>>> m = Dee.SequenceModel.new ()
>>> m.set_schema ("s", "i")
>>> m.append("hello", 27)

I get a Segmentation fault. Last night python lenses worked fine.

I attach apt history log from the upgrade that broke this.

Mikkel's pygobject fix just landed upstream.

http://git.gnome.org/browse/pygobject/commit/?id=c7aa0e79dfb4c1092c51ae1464b8414083b4f3fc

Hello David, or anyone else affected,

Accepted pygobject into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I've been using the patch for a few weeks now, without noticing any regressions.
I'm now testing the new package on two machines : everything seems fine and this bug is fixed.

Hello David,

David Callé [2011-10-25 8:58 -0000]:
> I've been using the patch for a few weeks now, without noticing any regressions.
> I'm now testing the new package on two machines : everything seems fine and this bug is fixed.

Thanks for testing! However, at the time you wrote this, the proposed
update was not yet on the mirrors. What package did you test in particular?

Martin

Hello Martin,
https://launchpad.net/ubuntu/+source/pygobject/3.0.0-0ubuntu4/+build/2875656

Ah, thanks :)

This bug was fixed in the package pygobject - 3.0.2-2

---------------
pygobject (3.0.2-2) experimental; urgency=low

  * debian/control.in: Add locales build dependency, to ensure that the test
    suite's localedef command can succeed.
  * debian/control.in: Bump g-i build deps to >= 1.31.0, as our test suite
    needs methods from that version.
  * Add 00git_marshal_gvariant_arrays.patch: Fix marshaling of arrays of
    GVariants. Thanks Mikkel Kamstrup Erlandsen! (LP: #855402)
 -- Martin Pitt <email address hidden> Thu, 27 Oct 2011 07:25:09 +0200

This bug was fixed in the package pygobject - 3.0.0-0ubuntu4

---------------
pygobject (3.0.0-0ubuntu4) oneiric-proposed; urgency=low

  * Add 00git_wrapper_ref.patch: When converting an object with transfer none,
    make sure the wrapper owns a ref. (LP: #874299)
  * Add 00git_marshal_gvariant_arrays.patch: Fix marshaling of arrays of
    GVariants. Thanks Mikkel Kamstrup Erlandsen! (LP: #855402)
 -- Martin Pitt <email address hidden> Tue, 25 Oct 2011 09:25:54 +0200