Message ID | ZdZuDfDPOToYAuRk@squeak.grove.modra.org |
---|---|
State | New |
Headers |
Return-Path: <binutils-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 302323858C42 for <patchwork@sourceware.org>; Wed, 21 Feb 2024 21:42:06 +0000 (GMT) X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id EB2B13858D1E for <binutils@sourceware.org>; Wed, 21 Feb 2024 21:41:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EB2B13858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EB2B13858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::436 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708551700; cv=none; b=qSm/Cb+bGZM0QrO83D+n2bR/sriWh1KU+PzR7nc7oZJWS5X+PQrH0e3EKZIXo5TGcaXNPTxx1LkogUAraSL+acULoEdMsBRIDSoiQuWMdEDEi3XAvPW3oK9ohwnr9Y7JBHTLlIazu1vm1AdQ5M9A9tdkwlcLWkstGm7gYS00VF0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1708551700; c=relaxed/simple; bh=KYPjzVfaqZRSU3jkfyQwHxbJUViJql+nVb7oc8udNjA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=ohjZM5n9nRMm9ktANNQxKpoUqd3hI/KbXS2Va+QZ32m7t/jZWQ2Zk8ptoG1iPiHI41vH2BGSjOar/1naK9nb6bAbs8oXIaDkMR+Zzv4WmSNd3qXailcGvFr0l3kwOy2iBw4g8jCSafh8kUix/LXPCyjvZJESMlRxmytPOOy7v4Q= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x436.google.com with SMTP id d2e1a72fcca58-6e43ee3f6fbso4196646b3a.3 for <binutils@sourceware.org>; Wed, 21 Feb 2024 13:41:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1708551697; x=1709156497; darn=sourceware.org; h=content-disposition:mime-version:message-id:subject:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=wfL3Pi7+xhkK6bq8nle7HWWPZsxOKcQfZKbo1QFW+dk=; b=ZvZfcE/A5YpL8m/9DC3ob4M3h0phHx8rA9eX+hGI6JHSDuWW/M9TLKfKhwMHl0f7gh cvIox8M2/ekJofR9DQY6y8tgMNJja6LzwgAzJAnGysB6RLkOV4DR2p70tb8GazIVFb03 j80hjzMfFbcZdRsRyF6SGNOnvNbK27n/9GPLihnuoRDCQAcjZTvFShn/PtGVAF76PKKr zjlmrPDvJspqaw0/OyeB5qcBN6iQErYWgC3jUODNCXZwLpxVuwUhCl5hESbJGw/z+xMg K9Bq92Ec4X27JJsd54fjOmJ9bv/N9sLIPFHPUvyZkoYzVE2eWLh0eLeAknxXgKb6WYy7 5ZLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708551697; x=1709156497; h=content-disposition:mime-version:message-id:subject:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wfL3Pi7+xhkK6bq8nle7HWWPZsxOKcQfZKbo1QFW+dk=; b=usXU7N3YxPryoJhFAz4aIqBtXKXH5tsqO2MPM06HT0nrpBOGd+2BXO8/nwnMOw2p57 qBOHNrf3B2smudYvQoQH05U6XWcLl0Z0NguQoFTI6qFEt4J4i/D2U7e0+cpdxGBYiF/1 oxyuXgjtGSZeN3dUuj8kOfQS8YjxQ7owVidBll6VXYX3LnZ8IaneUmJVmOXrq+uBDuph 2hcudbiVOTLyrHSw9s2u6FTGbyiW1CVYSfZUAGPnGkBrCNjsad30v5znqrT7w9fzk0RQ dUwW4FERaM/85vtN4IkeUvZDke6BP7OK2zXxtA6rgZQZiZ+Pp5xdcltYd1cb2IYGt1rm YWdA== X-Gm-Message-State: AOJu0Yxx847UHkgbl/ztaDHdrMOVVOwnH1/LIHZ3sqrQ/sxZsFft/Go+ Ngv3vH+8VJJWi0Dw5if73kMlEHAkf14gPTo+Zei4pSAb+otvApg5lrsBzM2S X-Google-Smtp-Source: AGHT+IGRyb5abIvxT05qKh9JZU8LD5ahh3eiCI3IcTcLZIDvcv8NBEtGPwqv2iQduanMXq3crE8HqQ== X-Received: by 2002:a05:6a21:1014:b0:1a0:c46f:62be with SMTP id nk20-20020a056a21101400b001a0c46f62bemr3022532pzb.38.1708551696896; Wed, 21 Feb 2024 13:41:36 -0800 (PST) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id k9-20020aa79d09000000b006e45c5d7720sm7393256pfp.93.2024.02.21.13.41.35 for <binutils@sourceware.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Feb 2024 13:41:36 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 906E21140496; Thu, 22 Feb 2024 08:11:33 +1030 (ACDT) Date: Thu, 22 Feb 2024 08:11:33 +1030 From: Alan Modra <amodra@gmail.com> To: binutils@sourceware.org Subject: Leak in i386_elf_section_change_hook Message-ID: <ZdZuDfDPOToYAuRk@squeak.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3033.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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 X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Binutils mailing list <binutils.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/binutils>, <mailto:binutils-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/binutils/> List-Post: <mailto:binutils@sourceware.org> List-Help: <mailto:binutils-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/binutils>, <mailto:binutils-request@sourceware.org?subject=subscribe> Errors-To: binutils-bounces+patchwork=sourceware.org@sourceware.org |
Series |
Leak in i386_elf_section_change_hook
|
|
Checks
Context | Check | Description |
---|---|---|
linaro-tcwg-bot/tcwg_binutils_build--master-arm | warning | Patch is already merged |
linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 | warning | Patch is already merged |
Commit Message
Alan Modra
Feb. 21, 2024, 9:41 p.m. UTC
notes_alloc is perfect for assorted memory you can't free easily and/or would rather leave freeing until just before exit. * config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc.
Comments
On 21.02.2024 22:41, Alan Modra wrote: > notes_alloc is perfect for assorted memory you can't free easily > and/or would rather leave freeing until just before exit. > > * config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc. > > diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c > index ed7c4a5ea03..c56ca4a2b4b 100644 > --- a/gas/config/tc-i386.c > +++ b/gas/config/tc-i386.c > @@ -17627,7 +17627,7 @@ i386_elf_section_change_hook (void) > break; > if (!curr) > { > - curr = XNEW (struct i386_segment_info); > + curr = notes_alloc (sizeof (*curr)); > curr->subseg = info->subseg; > curr->next = NULL; > prev->next = curr; > Just for my understanding: Is it an unwritten(?) requirement then that all XNEW()-ed (and alike) memory be freed before exiting? If so, why would that be? I can certainly see that library code may not leak memory, but something like gas, which is an isolated process, gives up all resources anyway once finished with the (singular) task. Jan
On Thu, Feb 22, 2024 at 10:20:50AM +0100, Jan Beulich wrote: > On 21.02.2024 22:41, Alan Modra wrote: > > notes_alloc is perfect for assorted memory you can't free easily > > and/or would rather leave freeing until just before exit. > > > > * config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc. > > > > diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c > > index ed7c4a5ea03..c56ca4a2b4b 100644 > > --- a/gas/config/tc-i386.c > > +++ b/gas/config/tc-i386.c > > @@ -17627,7 +17627,7 @@ i386_elf_section_change_hook (void) > > break; > > if (!curr) > > { > > - curr = XNEW (struct i386_segment_info); > > + curr = notes_alloc (sizeof (*curr)); > > curr->subseg = info->subseg; > > curr->next = NULL; > > prev->next = curr; > > > > Just for my understanding: Is it an unwritten(?) requirement then that > all XNEW()-ed (and alike) memory be freed before exiting? If so, why > would that be? I can certainly see that library code may not leak > memory, but something like gas, which is an isolated process, gives > up all resources anyway once finished with the (singular) task. As you say, there is very little reason to free memory that holds persistent data. In fact, freeing memory slows down gas, ld, and the binutils. The only reason we bother is that many people using shiny new tools that reports memory leaks, or automated checkers like oss-fuzz, don't care or aren't able to distinguish between leaks that matter and those that don't. This leak obviously doesn't matter, but a leak that occurred on every symbol evaluation would matter. Hopefully by tidying memory before exit we'll only see reports of leaks that matter.
diff --git a/gas/config/tc-i386.c b/gas/config/tc-i386.c index ed7c4a5ea03..c56ca4a2b4b 100644 --- a/gas/config/tc-i386.c +++ b/gas/config/tc-i386.c @@ -17627,7 +17627,7 @@ i386_elf_section_change_hook (void) break; if (!curr) { - curr = XNEW (struct i386_segment_info); + curr = notes_alloc (sizeof (*curr)); curr->subseg = info->subseg; curr->next = NULL; prev->next = curr;