[PATCH 2/2] Fix trivial memory leaks

[Pekka Paalanen]

On Sun, 8 Mar 2015 19:18:33 +0900
Ryo Munakata <ryomnktml at gmail.com> wrote:

> On Tue, 3 Mar 2015 12:04:23 +0200
> Pekka Paalanen <ppaalanen at gmail.com> wrote:
> 
> > >  
> > >  static void
> > > diff --git a/xwayland/launcher.c b/xwayland/launcher.c
> > > index df2efd2..63a1dea 100644
> > > --- a/xwayland/launcher.c
> > > +++ b/xwayland/launcher.c
> > > @@ -338,6 +338,8 @@ weston_xserver_destroy(struct wl_listener *l, void *data)
> > >  	if (!wxs)
> > >  		return;
> > >  
> > > +	wl_event_source_remove(wxs->sigusr1_source);
> > > +
> > >  	if (wxs->loop)
> > >  		weston_xserver_shutdown(wxs);
> > >  
> > 
> > This looks suspicious. There already is:
> > xwayland/launcher.c=39=handle_sigusr1(int signal_number, void *data)
> > xwayland/launcher.c:47:	wl_event_source_remove(wxs->sigusr1_source);
> > 
> > Doesn't this lead to double-remove?
> 
> Ahh, yes, you are right.
> I thought I saw valgrind reported this as a memory leak.
> Now I tested it with valgrind and this part seems to be my mistake.

Well, the leak could happen in the case where the Xwayland process
never sends a SIGUSR1 to us. So ideally you'd track if you need to
clean up or not. It's corner case from a failure path.


Thanks,
pq