MC seems to have a mixture of Qt-style parent/child relationships, and GObject refcounting. The "abort" signal "sometimes" causes objects to be destroyed cleanly, but sometimes doesn't. As a result, if one of the tests is made to fail at a random point, MC will probably critical and crash. (This is actually less damaging in the real world than in tests, because the tests deliberately make many warnings fatal, but in the real world MC will "probably" recover...) The long-term solution is to get rid of (at least) the McdMission/McdOperation parent/child structure, the abort signal, and the McdChannel channel/request duality.
One way to cause a chain of crashes is to comment out the early return from the check for self->priv->invoked_observers_if_needed in _mcd_dispatch_operation_check_client_locks in my mini-plugins branch, when I get it committed, and run the dispatch-delayed-by-plugin test.
-- 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/telepathy/telepathy-mission-control/issues/15.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.