From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 66EF01F953 for ; Tue, 26 Oct 2021 21:11:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237213AbhJZVNz (ORCPT ); Tue, 26 Oct 2021 17:13:55 -0400 Received: from cloud.peff.net ([104.130.231.41]:47408 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235666AbhJZVNy (ORCPT ); Tue, 26 Oct 2021 17:13:54 -0400 Received: (qmail 10612 invoked by uid 109); 26 Oct 2021 21:11:30 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Tue, 26 Oct 2021 21:11:30 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 13924 invoked by uid 111); 26 Oct 2021 21:11:30 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Tue, 26 Oct 2021 17:11:30 -0400 Authentication-Results: peff.net; auth=none Date: Tue, 26 Oct 2021 17:11:29 -0400 From: Jeff King To: Taylor Blau Cc: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason , git@vger.kernel.org, Junio C Hamano , Derrick Stolee Subject: Re: [PATCH] leak tests: add an interface to the LSAN_OPTIONS "suppressions" Message-ID: References: <211022.86sfwtl6uj.gmgdl@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, Oct 26, 2021 at 04:23:14PM -0400, Taylor Blau wrote: > So this all feels like a bug in ASan to me. I'm curious if it works on > your system, but in the meantime I think the best path forward is to > drop the last patch of my original series (the one with the three > UNLEAK() calls) and to avoid relying on this patch for the time being. Bugs aside, I'd much rather see UNLEAK() annotations than external ones, for all the reasons we introduced UNLEAK() in the first place: - it keeps the annotations near the code. Yes, that creates conflicts when the code is changed (or the leak is actually fixed), but that's a feature. It keeps them from going stale. - leak-checkers only know where things are allocated, not who is supposed to own them. So you're often annotating the wrong thing; it's not a strdup() call which is buggy and leaking, but the function five layers up the stack which was supposed to take ownership and didn't. And if we avoid any annotation bugs by doing so, that's icing on the cake. :) -Peff