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 707339 - gutterrenderer: use sourceview after destroy
gutterrenderer: use sourceview after destroy
Status: RESOLVED FIXED
Product: gtksourceview
Classification: Platform
Component: General
unspecified
Other Linux
: Normal major
: ---
Assigned To: GTK Sourceview maintainers
GTK Sourceview maintainers
Depends on:
Blocks:
 
 
Reported: 2013-09-03 02:21 UTC by Christian Hergert
Modified: 2013-10-27 16:23 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
renderegutterrendererlines: use g_signal_connect_object() (1.19 KB, patch)
2013-09-03 02:22 UTC, Christian Hergert
reviewed Details | Review

Description Christian Hergert 2013-09-03 02:21:58 UTC
When using multiple sourceviews to view a single buffer, destroying one of the sourceviews can cause the lines gutterrenderer to use view after it has been destroyed.
Comment 1 Christian Hergert 2013-09-03 02:22:55 UTC
Created attachment 253917 [details] [review]
renderegutterrendererlines: use g_signal_connect_object()

Fixes a bug where on_buffer_changed() is called after view has been disposed.
Comment 2 Paolo Borelli 2013-09-03 06:22:38 UTC
Review of attachment 253917 [details] [review]:

hystoricall g_signal_connect_object() was documented as a "broken" function that didn't do what it was supposed to do... is it fixed these days? [1]

Also, the handler_id is not set to 0 in this case... is this a problem?





[1] https://developer.gnome.org/gobject/2.30/gobject-Signals.html#g-signal-connect-object contains a note that's removed in the current docs.
Comment 3 Christian Hergert 2013-09-03 07:10:45 UTC
(In reply to comment #2)
> Review of attachment 253917 [details] [review]:
> 
> hystoricall g_signal_connect_object() was documented as a "broken" function
> that didn't do what it was supposed to do... is it fixed these days? [1]

I'm not sure on that, but it did fix my problem.

> Also, the handler_id is not set to 0 in this case... is this a problem?

Yes, when using multiple gtksourceview sharing the same buffer, I would hit this after destroying the second widget.

Alternatively, we can just make sure we disconnect them instead of connect_object.
Comment 4 Paolo Borelli 2013-09-03 07:16:54 UTC
Yes, I think we should use a weak_ref or a weak_pointer and disconnect ourselves and clear the handler
Comment 5 Sébastien Wilmet 2013-09-03 09:45:34 UTC
g_signal_connect_object() works as it is documented now. So I think it has been fixed.
Comment 6 Sébastien Wilmet 2013-09-28 18:02:05 UTC
Review of attachment 253917 [details] [review]:

For me the commit is good. It is not a problem that priv->changed_handler_id is not set to 0, because when the signal handler is disconnected automatically, the gutter renderer is disposed.
Comment 7 Sébastien Wilmet 2013-09-29 02:24:12 UTC
Review of attachment 253917 [details] [review]:

Well, if the buffer change between the dispose and finalize, there is a problem.
Why not simply disconnect the signal handler in dispose? we have the changed_handler_id and the current buffer anyway.