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

["Benjamin Purcell" <spew@cbza.org>]

My guess would be that Steve's email client does something weird with leading whitespace.

On Sat, Jan 21, 2023, at 18:36, Dan Cross wrote:
> 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])