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 623537 - GDBusProxy has weird checking on NameOwnerChanged
GDBusProxy has weird checking on NameOwnerChanged
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gdbus
unspecified
Other All
: Normal trivial
: ---
Assigned To: David Zeuthen (not reading bugmail)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2010-07-04 18:07 UTC by Allison Karlitskaya (desrt)
Modified: 2010-07-07 13:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2010-07-04 18:07:37 UTC
The 'on_name_owner_changed' function is a little bit weird.  I'll paste the starting part:

----

{
  GDBusProxy *proxy = G_DBUS_PROXY (user_data);
  const gchar *name;
  const gchar *old_owner;
  const gchar *new_owner;

  /* if we are already trying to load properties, cancel that */
  if (proxy->priv->get_all_cancellable != NULL)
    {
      g_cancellable_cancel (proxy->priv->get_all_cancellable);
      proxy->priv->get_all_cancellable = NULL;
    }

  g_variant_get (parameters,
                 "(&s&s&s)",
                 &name,
                 &old_owner,
                 &new_owner);

  /* we only care about a specific name */
  if (g_strcmp0 (name, proxy->priv->name) != 0)
    goto out;

----


Why are we cancelling the pending property query before we bail out due to having the incorrect name?  That really looks like a bug.

Of course, I think the real issue is probably that there's no bug at all but rather it's impossible for the strcmp to fail (since when we register for the signal we already specify the arg0 as part of the match rules).  In that case probably we should remove it entirely.

Either way, something should be changed.
Comment 1 David Zeuthen (not reading bugmail) 2010-07-07 13:10:26 UTC
(In reply to comment #0)
> Of course, I think the real issue is probably that there's no bug at all but
> rather it's impossible for the strcmp to fail (since when we register for the
> signal we already specify the arg0 as part of the match rules).  In that case
> probably we should remove it entirely.

Yup, fixed that (and the lcov output also shows that the 'goto out' path never ran - lcov FTW!). Thanks for pointing this out.

http://git.gnome.org/browse/glib/commit/?id=ea0607438bfb1fb2ae7cd22757ecdb53946a00b0