Bug 24794

Summary: memory management makes no sense
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: mission-controlAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED MOVED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Simon McVittie 2009-10-29 12:23:48 UTC 
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.
Comment 1 Simon McVittie 2009-10-29 12:26:56 UTC 
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.
Comment 2 GitLab Migration User 2019-12-03 19:33:47 UTC 
-- 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.