Re: [PATCH 0/7] Attempt to detect leaks in spice-server

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 2015-10-15 at 04:01 -0400, Frediano Ziglio wrote:
> Hi,
>   on the other side I wrote these patches thinking about refactory
> job.
> There are so many changes that having a good way to test for leaks is
> good.
> Not all are GObject and having destructors does not prevent leaks,
> you still
> have to call them in some way, is not like a language having
> automatic
> garbage collector.


I didn't mean to imply that the existence of a destructor will prevent
leaks. I only meant that some of the new "destructor" functions that
you are adding in this patch series (e.g. dispatcher_destroy) already
exist in the refactory branch (e.g. dispatcher_finalize). So this will
create some merge conflicts. Maybe they'll be easy to resolve though.
And I agree that it is probably good to have a way to detect new leaks
as we merge the refactory changes.

Jonathon


> 
> Frediano
> 
> > 
> > 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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]     [Monitors]