Hi Frediano, I'm a bit conflicted about this patch series. Some of this stuff is already handled (or at least partially handled) in the 'refactory' branch. Since some of these objects have been refactored into GObjects in that branch, they now have destructor functions that clean things up. Of course, not all objects are being freed properly in the refactory branch, but I fear that if we start adding these new functions to master it may make it more difficult to rebase or merge the refactory branch. Thoughts? Jonathon On Wed, 2015-10-14 at 16:37 +0100, Frediano Ziglio wrote: > In order to better detect leaks inside the library I'm attempting > to implement a way to destroy QXL dispatcher and worker so to make > possible for a test to invoke it and then check if there are still > memory allocated. > > The main idea is to use with spice-server-replay to be able to detect > possible leaks. > > Actually I was able to find a leak in the MJPEG code. > > Frediano Ziglio (7): > add dispatcher_destroy function > add a red_memslot_info_destroy function > red_worker: add RED_WORKER_MESSAGE_CLOSE_WORKER message > add red_dispatcher_destroy function > support QXL remove on spice_server_remove_interface > implements handle_dev_close > replay: free QXL interface to detect leaks > > server/dispatcher.c | 12 +++++++++++ > server/dispatcher.h | 6 ++++++ > server/red_dispatcher.c | 54 > +++++++++++++++++++++++++++++++++++++++++++++++++ > server/red_dispatcher.h | 4 ++++ > server/red_memslots.c | 10 +++++++++ > server/red_memslots.h | 1 + > server/red_worker.c | 44 > ++++++++++++++++++++++++++++++++++++++++ > server/red_worker.h | 3 +++ > server/reds.c | 9 +++++++++ > server/tests/replay.c | 2 ++ > 10 files changed, 145 insertions(+) > _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel