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 774593 - Gio::SettingsSchemaSource::get_default() does not ref the returned object, leading to a trap at app exit
Gio::SettingsSchemaSource::get_default() does not ref the returned object, le...
Status: RESOLVED FIXED
Product: glibmm
Classification: Bindings
Component: giomm
2.50.x
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2016-11-16 20:31 UTC by Daniel Boles
Modified: 2016-11-19 20:15 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix (1.06 KB, patch)
2016-11-16 20:55 UTC, Marcin Kolny (IRC: loganek)
none Details | Review

Description Daniel Boles 2016-11-16 20:31:52 UTC
After having used Gio::SchemaSettingsSource::get_default() earlier in my program, I was getting the following crash every time the program closed:

> GLib-GIO-ERROR **: g_settings_schema_source_unref() called too many times on the default schema source
> Trace/breakpoint trap

I found that to avoid this, I must call refPtr_schemaSettingsSource->reference() manually.

I haven't set breakpoints etc yet, but my intuition is that the RefPtr going out of scope causes the default SSS to be unref'd, making the later unref at exit bail out.

This seems wrong and contrary to my understanding of RefPtrs: I would expect that by calling get_default(), the default SSS would be ref'd to 2 (I guess), then the RefPtr will go out of scope soon and decrement the ref count to 1, ready for unrefing at exit. But this doesn't seem to happen.

It also seems problematic because the documentation explicitly says that...

> void Gio::SettingsSchemaSource::reference() const
>   Increment the reference count for this object.
>   You should never need to do this manually - use the object via a RefPtr instead.

I _am_ using it via a RefPtr, and yet I _do_ need to call it manually to avoid an ugly crash every time my program ends. Why is this?

Thanks in advance!
Comment 1 Marcin Kolny (IRC: loganek) 2016-11-16 20:55:07 UTC
Created attachment 340074 [details] [review]
fix

That's correct, the method returns transfer-none, but we don't do refreturn. I'm attaching the fix. Please review, if ok - will push it.
Comment 2 Daniel Boles 2016-11-16 21:32:12 UTC
Thank you! That makes sense by my understanding of the reference model, but because that understanding
Comment 3 Daniel Boles 2016-11-16 21:33:02 UTC
...is quite basic, probably a 3rd opinion is a good idea. :)
Comment 4 Marcin Kolny (IRC: loganek) 2016-11-19 10:28:53 UTC
Since no comments, I'm pushing the patch.
Comment 5 Daniel Boles 2016-11-19 11:43:03 UTC
Can it be cherry-picked to 2-50? Thanks!
Comment 6 Murray Cumming 2016-11-19 20:15:25 UTC
Done.