Re: [9front] lock: Fix some memory leaks

[Dan Cross <crossd@gmail.com>]

On Sat, Jan 21, 2023 at 3:52 AM Steve Simon <steve@quintile.net> wrote:
> sorry, but this patch looks very wrong.
>
> free after return does nothing.
> calling waitfor twice allocates data twice.

I've got no real context here, but a couple of brief observations: The
`return` mentioned above is conditional on some pid having an expected
value. The `free` added in this patch is for the non-return case where
the conditional does not evaluate to true.

I don't see how `waitfor` is called twice in this patch. Rather, it
appears that a call to `waitfor(...)` was replaced with
`free(waitfor(...))`

> i would also consider what happens after the waitfor() call - i have not looked at the source but i have a suspicion that lock exits, so there is no point in freeing memory anyway.

It does appear that `lock` exits here.

        - Dan C.

> > On 21 Jan 2023, at 12:18 am, Josiah Frentsos <jfrent@tilde.team> wrote:
> >
> > diff bb36ba0617b5aa8263ea9b5ece8c1a5249fedc86 uncommitted
> > --- a/sys/src/cmd/lock.c
> > +++ b/sys/src/cmd/lock.c
> > @@ -35,6 +35,7 @@
> >        }
> >        if (w->pid == pid)
> >            return w;
> > +        free(w);
> >    }
> > }
> >
> > @@ -141,7 +142,8 @@
> >        error("wait");
> >
> >    postnote(PNPROC, lckpid, "die");
> > -    waitfor(lckpid);
> > +    free(waitfor(lckpid));
> > +
> >    if(w->msg[0]){
> >        p = utfrune(w->msg, ':');
> >        if(p && p[1])