From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 8C94D3858D37 for ; Wed, 17 Aug 2022 19:03:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8C94D3858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=konscious.net Authentication-Results: sourceware.org; spf=none smtp.mailfrom=konscious.net Received: by mail-pf1-x42b.google.com with SMTP id z187so12794524pfb.12 for ; Wed, 17 Aug 2022 12:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konscious-net.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=9KY1QAGSzcH6hkrbEgWJJ7FdL9ZWx4L9Efc1vEz9Qc8=; b=iDx5itWRfsHDCMchRrhbFIaIaYc+p4UE8zNNpG3dO8OgPLIwoUwUTvdOfdw4Z9QuUk w0BapJYtr7UVB2LYWOI/nDky5Ze8P2gpUA22GtCZ+Bto+9xGXKKkHQsx6kzs8xUzpzEw 8dI04Np/i/z5Jn3CTcf0CYVOhM6G4/TVeK2H7Xe8Xn1lF3Z22Ncr7EzGwpsj9Mxcpvpg /YSo+zueOWQ+Y1kSl7X7d4QU0O1fM/YIgwGCAtu0CWkSJxGU0TI1Ho3W9nPtc35i7Pkh HF6Y5hum/sKk6qhkr8yqyfUgdOIV43w2LgFXHchS0Df2VZ/uDQk9czLm4EaqHF68vDxn Uc8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=9KY1QAGSzcH6hkrbEgWJJ7FdL9ZWx4L9Efc1vEz9Qc8=; b=hmYyXEgrUGpfDgWOFQYbkIrJnmwnXqdhObNxcnoiXvWo4R0J3t22uUr4BNK30fFekY UhY5RtsM9Bjf8OTZJ9cqZ7hgy1RpGIrtHrcJ7qkHx2mgS9pzNY4NPnB5oR5jYOGuh+tL VVZ3t0M6N/bt7ZG1XWsGXNMZ54skkm9CeUdHQex7IfQUzpaqYk6y9XJauv3q/9zRk6FS VsndtpAY/7FvtZEidrxCCdiVIA/gLO0Cb8hlQBisV3AQB5pQ8WG1VuWHAqfCp5CtChuO RKAdo0ZSpVOBmshMdxSDTX8qbiCihLuWEPV2lgfPqIXfi18lIA6OHEWaWc4nku70EuXl FKMw== X-Gm-Message-State: ACgBeo3XE/7hvUb9qPywBx0EtOY8fRvelx3yG/YqixqrC4hBnB5JkhFd BDRv23ei74HGUTdALqLw2Waj2SDnapp30jmDTkAo X-Google-Smtp-Source: AA6agR7drlb9T+8yWD4hCTMg5KKbPrLhJ4B5sGI47CmQBORVmAeWx/PRYNkJ/vYG6UorKiL/4lmzsl8oTldqgvSuZFE= X-Received: by 2002:a63:1c0b:0:b0:429:f504:e9a1 with SMTP id c11-20020a631c0b000000b00429f504e9a1mr272183pgc.319.1660762990312; Wed, 17 Aug 2022 12:03:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Keef Aragon Date: Wed, 17 Aug 2022 12:02:59 -0700 Message-ID: Subject: Re: [PATCH] bug in emergency cxa pool free() To: Richard Biener Cc: "libstdc++" , GCC Patches , Jonathan Wakely X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2022 19:03:14 -0000 Thank you! I was working on a modified version that I could LD_PRELOAD to investigate some issues I was having in my asynchronous application code. It used a higher order collection of pool instances instead of malloc/free, with extra context (an array of pc register values) packed into the buffer before the refcounted exception. in_pool on the pools in the collection is the safety check to know that the extra context can be safely pulled from the pointer. With that implementation, memory was being leaked because the destruction of one of the pools in the collection requires there to be no more uses of it and quickly checking for that to be the case also needed the ordered invariant to hold (just checking if the freelist the whole arena). On Tue, Aug 16, 2022 at 11:45 PM Richard Biener wrote: > On Tue, Aug 16, 2022 at 9:15 PM Keef Aragon > wrote: > > > > This probably has never actually affected anyone in practice. The normal > > ABI implementation just uses malloc and only falls back to the pool on > > malloc failure. But if that happens a bunch of times the freelist gets > out > > of order which violates some of the invariants of the freelist (as well > as > > the comments that follow the bug). The bug is just a comparison reversal > > when traversing the freelist in the case where the pointer being returned > > to the pool is after the existing freelist. > > > > I'm not sure what to do as far as the test suite is concerned. It's a > > private part of the implementation of the exception handling ABI and it > can > > only ever be triggered if malloc fails (repeatedly). So it seems like > > reproducing it from the external interface will require hooking malloc to > > forcibly return NULL. > > > > But I'm a newb on these lists, so will obediently do as instructed. > > Oops, that's my fault. > For consistency it's probably best written > as reinterpret_cast (e) + sz > reinterpret_cast ((*fe)) > thus > > diff --git a/libstdc++-v3/libsupc++/eh_alloc.cc > b/libstdc++-v3/libsupc++/eh_alloc.cc > index c85b9aed40b..68f319869f9 100644 > --- a/libstdc++-v3/libsupc++/eh_alloc.cc > +++ b/libstdc++-v3/libsupc++/eh_alloc.cc > @@ -224,8 +224,8 @@ namespace > free_entry **fe; > for (fe = &first_free_entry; > (*fe)->next > - && (reinterpret_cast ((*fe)->next) > - > reinterpret_cast (e) + sz); > + && (reinterpret_cast (e) + sz > + > reinterpret_cast ((*fe)->next)); > fe = &(*fe)->next) > ; > // If we can merge the next block into us do so and continue > > The change is OK with that adjustment. I see you do not have write access > so > I'll test & push it for you. > > I'm curious how you noticed? > > Thanks, > Richard. >