After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 795265 - [PATCH] vapi: json-glib make gvariant_deserialize return nullable
[PATCH] vapi: json-glib make gvariant_deserialize return nullable
Status: RESOLVED FIXED
Product: vala
Classification: Core
Component: Bindings
unspecified
Other Linux
: Normal normal
: 0.42
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2018-04-14 18:23 UTC by David Hewitt
Modified: 2018-04-15 17:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[PATCH] vapi: json-glib make gvariant_deserialize return nullable (1.43 KB, patch)
2018-04-14 18:23 UTC, David Hewitt
none Details | Review
Also update metadata (2.41 KB, patch)
2018-04-15 10:46 UTC, David Hewitt
none Details | Review
vala: Treat floating method-return-type as nullable if error may be thrown (1.44 KB, patch)
2018-04-15 11:31 UTC, Rico Tzschichholz
committed Details | Review

Description David Hewitt 2018-04-14 18:23:16 UTC
Created attachment 370940 [details] [review]
[PATCH] vapi: json-glib make gvariant_deserialize return nullable

I've submitted a merge request here to fix the GIR generation:
https://gitlab.gnome.org/GNOME/json-glib/merge_requests/10

The changes to the vapi were generated by vapigen after running it on the GIR as updated in the merge request above.

The lack of the nullable flag was causing me some memory leak issues when those methods returned null.
Comment 1 Rico Tzschichholz 2018-04-15 06:13:02 UTC
@david Could you provide an example which shows the mentioned memory leak?
Comment 2 David Hewitt 2018-04-15 08:47:56 UTC
Sorry, after doing some more testing, I think the memory leak issues are unrelated to this.

It seems like some unhanded exceptions/assertions that were caused by calling g_variant_ref_sink and using one of the NULL pointers returned by the patched methods later on in my code was what was causing issues.

I don't think there's anything more to be done in Vala for this, as adding the nullable flag causes g_variant_ref_sink to be wrapped in a null check.
Comment 3 Rico Tzschichholz 2018-04-15 10:17:56 UTC
I see. I was wondering if we can catch that somehow by not unconditionally calling ref_sink on possible null.

Meaning, if the origin of the floating instance comes from a function which throws an error then treat it as nullable.
Comment 4 Rico Tzschichholz 2018-04-15 10:20:16 UTC
Review of attachment 370940 [details] [review]:

This can't be applied this way. Either wait for upstream annotations are fixed and source gir is updated, or the corresponding metadata is required.
Comment 5 David Hewitt 2018-04-15 10:46:18 UTC
Created attachment 370953 [details] [review]
Also update metadata
Comment 6 David Hewitt 2018-04-15 10:48:01 UTC
(In reply to Rico Tzschichholz from comment #3)

> Meaning, if the origin of the floating instance comes from a function which
> throws an error then treat it as nullable.

That may be worthwhile, I suppose it's quite common for the returned pointer to be null if there was an error thrown in the method.
Comment 7 Rico Tzschichholz 2018-04-15 11:31:45 UTC
Created attachment 370954 [details] [review]
vala: Treat floating method-return-type as nullable if error may be thrown
Comment 8 Rico Tzschichholz 2018-04-15 17:45:42 UTC
Comment on attachment 370954 [details] [review]
vala: Treat floating method-return-type as nullable if error may be thrown

Attachment 370954 [details] pushed as d6be549 - vala: Treat floating method-return-type as nullable if error may be thrown