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 746139 - popover: Fix crash when popover is NULL
popover: Fix crash when popover is NULL
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 755499 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-03-13 09:23 UTC by Bastien Nocera
Modified: 2017-08-03 21:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
popover: Fix crash when popover is NULL (1.58 KB, patch)
2015-03-13 09:23 UTC, Bastien Nocera
rejected Details | Review

Description Bastien Nocera 2015-03-13 09:23:55 UTC
.
Comment 1 Bastien Nocera 2015-03-13 09:23:59 UTC
Created attachment 299275 [details] [review]
popover: Fix crash when popover is NULL

When the popover was NULL, we'd access invalid memory before the
g_return_if_fail guards.
Comment 2 Carlos Garnacho 2015-03-13 12:40:52 UTC
Review of attachment 299275 [details] [review]:

Oops. Looks good to me
Comment 3 Matthias Clasen 2015-03-13 12:42:26 UTC
Review of attachment 299275 [details] [review]:

We generally don't accept NULL as a valid argument where an object is expected, unless it is explicitly annotated.
Comment 4 Matthias Clasen 2015-03-13 12:42:57 UTC
Which is why these accesses to priv pointers are safe (we do them all over the place)
Comment 5 Matthias Clasen 2015-03-13 12:43:39 UTC
And our policy for hitting a return_if_fail is: it might as well have crashed.
Comment 6 Bastien Nocera 2015-03-13 13:09:59 UTC
First time I hear that. What's wrong with failing gracefully?
Comment 7 Emmanuele Bassi (:ebassi) 2015-03-13 13:23:59 UTC
(In reply to Bastien Nocera from comment #6)
> First time I hear that. What's wrong with failing gracefully?

Considering that GLib (and basically every other library in the G* stack using GLib for precondition checks) can be compiled with all the g_return_* macros disabled, you will get a crash anyway later on — and not even a critical warning.

In general, and in accordance to what Matthias said in comment #4, the private data access should be done through the get_instance_private() accessor, instead of using a priv pointer, as that is NULL-instance-pointer safe.
Comment 8 Matthias Clasen 2015-03-13 13:47:44 UTC
(In reply to Bastien Nocera from comment #6)
> First time I hear that. What's wrong with failing gracefully?

Nothing wrong with it. I just don't want to establish prior art that would render

func (Foo *foo,...)
{
  FooPrivate *priv = foo->priv;
}

suspect. I use that idiom a lot, and don't want to start getting patches to eliminate it all over gtk...
Comment 9 Daniel Boles 2017-08-03 21:15:45 UTC
*** Bug 755499 has been marked as a duplicate of this bug. ***
Comment 10 Daniel Boles 2017-08-03 21:16:05 UTC
Timm fixed these in commit 0d17421ffdc3b6d3d47eaa38791f84e6111fe3f0