Bug#835413: pygobject: wrong enum to hash conversion on 64-bit big endian

[Aurelien Jarno]

control: tag -1 + patch

On 2016-08-25 14:16, Aurelien Jarno wrote:
> On 2016-08-25 09:15, Aurelien Jarno wrote:
> > I have tried to debug the issue, and I came to the same conclusion. The
> > problem happens in the test-py-lookup.py test when creating a schema
> > with Secret.Schema.new. The schema is defined in python using a
> > dictionary which is then transformed by gobject-introspection into a
> > to a GHashTable in order to call secret_schema_newv. This hash table
> > maps strings to enum (ie a 32-bit value).
> > 
> > In practice the hash table stores two gpointers, so the 32-bit value
> > has to be converted first to a pointer using GINT_TO_POINTER and when
> > read again converted with GPOINTER_TO_INT. The latter is correctly done
> > in libsecret, but the former doesn't seems to be done in
> > gobject-introspection. Therefore on a 64-bit little endian system, the
> > lower 32 bits are stored correctly, but the high 32 bits are left
> > unchanged as garbage. It's not a problem as GPOINTER_TO_INT just remove
> > this garbage. On a 64-bit big endian system, the value is stored on the
> > higher 32-bits, and the lower 32 bits are left unchanged as garbage.
> > Therefore GPOINTER_TO_INT just trash the value, just leaving the
> > garbage.
> > 
> > By changing the conversion in secret_schema_newv from
> >   type = GPOINTER_TO_INT (value);
> > to
> >   type = (gint)(((unsigned long) value) >> 32);
> > the testsuite is able to pass.
> > 
> > Of course this is not an acceptable patch and now we have to find where
> > in the whole gobject-introspection chain where to add the missing
> > GINT_TO_POINTER conversion.
> 
> The problem is actually in pygobject. enums are represented with a
> GI_TYPE_TAG_INTERFACE type, which corresponds to an "extended
> interface object". They are treated by _pygi_arg_to_hash_pointer (in
> gi/pygi-argument.c) as a pointer instead of a 32-bit value. The correct
> way to do that is to pass a GITypeInfo to the function so that it's
> possible to query the subtype of the GI_TYPE_TAG_INTERFACE type.
> 
> I am therefore cloning this bug and reassigning the clone to pygobject.
> I don't simply reassigning it as the /collection/delete-sync test is
> also failing, though it seems to not be fully reproducible and seems to
> also happen on other architectures (mipsel for example).
> 
> I have a dirty patch that works, I'll work on cleaning it so that it can
> be applied. It might take a few days.

Please find a patch attached. It fixes the test-py-lookup.py test in
libsecret so that it doesn't hang nor fail.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien at aurel32.net                 http://www.aurel32.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-list-hashtable-enum-hash-conversion-on-64-bit-bi.patch
Type: text/x-diff
Size: 8135 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20160826/dc36c546/attachment-0003.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20160826/dc36c546/attachment-0003.sig>