(In reply to Matthijs van Duin from comment #0)
> When RemoveMatch fails, it sends a
> org.freedesktop.DBus.Error.MatchRuleNotFound error after first sending a
> normal method return. As a result, clients are unable to determine that
> RemoveMatch failed.

That is indeed a bug, although I'm curious why you would ever handle an error from RemoveMatch() (it can't fail unless you remove a match rule that you never successfully added, which is not something that a correct application should ever end up doing).

(In reply to Simon McVittie from comment #1)
> That is indeed a bug, although I'm curious why you would ever handle an
> error from RemoveMatch() (it can't fail unless you remove a match rule that
> you never successfully added, which is not something that a correct
> application should ever end up doing).

It wasn't clear to me from documentation how adding the same rule twice would behave, i.e. whether the last add/remove would take effect or whether they would balance, so I experimented a bit and briefly got rather confused by not getting any errors at all. That's how I bumped into this.

But sure, in practice it isn't hugely important. Failures from RemoveMatch would mostly be useful as indication of application bugs. It also just struck me as odd that a method call could return twice.

I'd be happy to review a patch if you get round to it before a maintainer does.

I'd also be happy to review a patch to doc/dbus-specification.xml.in (or other relevant documentation) that specified what happens when you add the same rule more than once (I *think* the answer is that nothing special happens, and to remove it you have to call RemoveMatch() the same number of times you called AddMatch(), but please check).

(In reply to Matthijs van Duin from comment #0)
> When RemoveMatch fails, it sends a
> org.freedesktop.DBus.Error.MatchRuleNotFound error after first sending a
> normal method return. As a result, clients are unable to determine that
> RemoveMatch failed.

This is harder to fix than you might think:

  /* Send the ack before we remove the rule, since the ack is undone
   * on transaction cancel, but rule removal isn't.
   */
  if (!send_ack_reply (connection, transaction,
                       message, error))
    goto failed;

  matchmaker = bus_connection_get_matchmaker (connection);

  if (!bus_matchmaker_remove_rule_by_value (matchmaker, rule, error))
    goto failed;

  bus_match_rule_unref (rule);

  return TRUE;

The problem is that we are trying to carry out the requested operation transactionally: if we can do the whole operation, we want to do so, but if any part of it fails due to lack of memory, we want to not have any side-effects.

What we need to do is to have some way to allocate the required memory to send the successful reply (and perhaps even queue it for sending in the BusTransaction object), but then cancel sending the successful reply in the case where bus_matchmaker_remove_rule_by_value() fails.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/175.