From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 23913 invoked from network); 22 Jan 2023 07:10:40 -0000 Received: from 9front.inri.net (168.235.81.73) by inbox.vuxu.org with ESMTPUTF8; 22 Jan 2023 07:10:40 -0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by 9front; Sun Jan 22 02:09:28 -0500 2023 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 677E65C00C5 for <9front@9front.org>; Sun, 22 Jan 2023 02:09:27 -0500 (EST) Received: from imap45 ([10.202.2.95]) by compute6.internal (MEProxy); Sun, 22 Jan 2023 02:09:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cbza.org; h=cc :content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; t=1674371367; x= 1674457767; bh=/o+ScCf59qCahoII3bp4j4uZm1O4a0MGOz+CwqmW6EA=; b=0 lB/fLdpmee9w5SdxNCPxTSdAlwqECMjTorUhIS0wPRLU6szG+RcdmfKD+dpYA/ZH oqX0lk2hxyVx88kUCwq7yUbd+nTrinQOjrgZHbKDkEMKUoYcSugMFPAlZyou0x1W oT45VWiBZl8T7kcAKWcU9HZvYWQAb/UIsBj1llwZaLEaOJiX8z1t2D0WwBV9TfHj hzTqmoUQ7S8mIsX6L6aprqeGNc54UTTE/82sUUn2lIoY+wfkx3Lo85NbqAmrJiQ/ cZY3OuLyBiudsJIVAGm9gJYD1oG1108u9mE3S39bsvnimuMWW893M7tg8jU6+ppr gK9WOf2YvFTIscTQixnjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; t=1674371367; x=1674457767; bh=/ o+ScCf59qCahoII3bp4j4uZm1O4a0MGOz+CwqmW6EA=; b=eZIxL2Ttkyx1CW+GL OqD2OJMhec+xEc6JPgSXGfbGxlkMg8y90d2eYccNKMbZbhTRFomV/HNmB+MOHIiw ixATUxRYCtRHO9Mz0SQfhQc0AzQCiyFllPbyGnHUpiMbwx1ODhRSp3fprjxDV1Gq u6nNShOJbwgOfvUOgDXlyaruTiadL9NiOCl0cG6XYtxdP8+biBh0j6XoILqUnHda rKGFfyHOPdkphffHZKv9DQUNWZsZJ/AoaZBHqu4uJrqUR+Ml1pKLuoN+dqiOKiWN UJ77Sa/d1t/h6i9FnpdM064eClrEei6Itcut4IBtW/2THZoyE/x6bw1hD6Pst5Rs Vhpjg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudduhedguddthecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedfuegvnhhjrghmihhnucfruhhrtggvlhhlfdcuoehs phgvfiestggsiigrrdhorhhgqeenucggtffrrghtthgvrhhnpeetveelhfdttefgtddtue eugeefleeugfeftdeitedtgfffteffueehtdelveeukeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsphgvfiestggsiigrrdhorhhg X-ME-Proxy: Feedback-ID: i89414493:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 21B99272007B; Sun, 22 Jan 2023 02:09:27 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-85-gd6d859e0cf-fm-20230116.001-gd6d859e0 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Sun, 22 Jan 2023 01:09:24 -0600 From: "Benjamin Purcell" To: 9front@9front.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: compliant anonymous replication extension Subject: Re: [9front] lock: Fix some memory leaks Reply-To: 9front@9front.org Precedence: bulk My guess would be that Steve's email client does something weird with le= ading whitespace. On Sat, Jan 21, 2023, at 18:36, Dan Cross wrote: > On Sat, Jan 21, 2023 at 3:52 AM Steve Simon 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 ther= e 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 wr= ote: >> > >> > =EF=BB=BFdiff bb36ba0617b5aa8263ea9b5ece8c1a5249fedc86 uncommitted >> > --- a/sys/src/cmd/lock.c >> > +++ b/sys/src/cmd/lock.c >> > @@ -35,6 +35,7 @@ >> > } >> > if (w->pid =3D=3D 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 =3D utfrune(w->msg, ':'); >> > if(p && p[1])