GNOME Bugzilla – Bug 691638
item_get_attributes_sync introspection is broken
Last modified: 2021-06-18 13:52:46 UTC
Via introspected python bindings at least, item_get_attributes_sync is broken. It kinda works but crashes hard with a double free. Patch adds annotations that make it work, but it might be breaking the abstraction a bit by specifically labelling the AttributeList as a GArray.
Created attachment 233361 [details] [review] Fix introspection of item_get_attributes_sync These annotations make this API functional for me via python, however behavior is a bit inconsistent: it will return a python list() of Attributes, while GnomeKeyring.attribute_list_new() will return a GArray.
Can we make GnomeKeyringAttributeList always map to list types in introspected languages? Can we do this without breaking API? Evan, what do you think is the right way to solve this.
(In reply to comment #2) > Can we make GnomeKeyringAttributeList always map to list types in introspected > languages? Unfortunately not automatically. Bug #629682. It would have to be done for each argument. > Can we do this without breaking API? Evan, what do you think is the > right way to solve this. In order to avoid breaking the Vala API we would need to basically reverse the proposed changes in the metadata file... something like this should do the trick: item_get_attributes_sync.attributes type="GnomeKeyring.AttributeList" Of course it doesn't really make sense to change this one function and leave all the other functions with GnomeKeyringAttributeList arguments. If you want I can put together a patch later this week (Thursday or Friday probably).
Well I don't really care what's implemented, as long as it's consistent with the other uses of the attribute list. Can we now just mark @attributes as (out)? Does GI scanner still crash when we do this (if so, can we fix it). Evan, yes a patch would be nice, thanks.
g-ir-scanner still crashes: Traceback (most recent call last):
+ Trace 231380
sys.exit(scanner_main(sys.argv))
main.transform()
self._namespace.walk(self._pass_read_annotations)
node.walk(callback, [])
res = callback(self, chain)
self._apply_annotations_function(node, chain)
self._apply_annotations_callable(node, chain, block)
self._apply_annotations_params(node, node.parameters, block)
self._apply_annotations_param(parent, param, tag)
self._apply_annotations_param_ret_common(parent, param, tag)
target = self._transformer.resolve_aliases(target)
typenode = ast.type_names[typenode.target.target_fundamental]
I poked at it a bit but didn't understand what is going on.
Colin may have an idea why it's crashing. Colin, to reproduce this, we just use libgnome-keyring from git master and apply the following change: --- a/library/gnome-keyring.c +++ b/library/gnome-keyring.c @@ -3893,3 +3893,3 @@ gnome_keyring_item_get_attributes (const char * @id: The id of the item - * @attributes: The location to return a pointer to the attribute list. + * @attributes: (out): The location to return a pointer to the attribute list. *
Typedefs for container types are basically just not supported right now, as Evan said in Comment 3.
So I tried: @attributes: (out) (type GnomeKeyring.AttributeList) and @attributes: (out) (element-type GnomeKeyringAttribute) (type GnomeKeyring.AttributeList) g-ir-scanner crashes as above. Doing just @attributes: (type GnomeKeyring.AttributeList) Doesn't fix things with the python bindings: it still wants an attributelist passed to item_get_attributes_sync which isn't ever going to work. Evan, any thoughts?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of libgnome-keyring, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/libgnome-keyring/-/issues/ Thank you for your understanding and your help.