From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by sourceware.org (Postfix) with ESMTPS id 1283A3858D28 for ; Sat, 18 Dec 2021 19:36:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1283A3858D28 Received: by mail-yb1-xb2e.google.com with SMTP id f9so16238748ybq.10 for ; Sat, 18 Dec 2021 11:36:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D5sd1KVcBA3YxG8LZpZSy4RT34g+dlq7HALenjYRA3k=; b=avXhFx1Wu3tviGSGncTOmbR8QQBAHPlau6EJ6Vytz17diGPCyXjU9cNGqWCV13xHJU NBm7g9AOIK19Bv5AZ5JtCVetJcl9Idl4jQBxTWHpOh2FdZXvdl0o2/kjhxVNl7SiHGrd jtMJhcJP5vE+OE06m4/GePm4lD8DN5AuW0vCObEuIdJfc9zGpxaHZ9E7natoM0FrJlPM +lw3Q3v7CqH/gtPdDWVQlBis7Ien7mNR1Njveg3z+F2+Mr994U8DSLdECFC2lBoAJ/ag NkJKxidf9JLhQAOf4JC6BTrpS5qcjK9mEMYD+foEDEDnBI3EbAbtvsRcxOrpcm/yyCEK TeWA== X-Gm-Message-State: AOAM532xrm+aRakywJ7iTunkYfNbw9Fz2wx17kalInkhirWIff6I9nbF IGB3dR+ivTM6AWNBX398NKDDtFA8+J/GQX6u0Pw= X-Google-Smtp-Source: ABdhPJyd53sfltp8YgzMmKU4uNSSkGZrTJcIh2F+VAfJmNSfyNMbEeLa3XOQ/A1JWhEs0VQANEbbdel84ZbudaJI9Oc= X-Received: by 2002:a25:e755:: with SMTP id e82mr11826300ybh.389.1639856198463; Sat, 18 Dec 2021 11:36:38 -0800 (PST) MIME-Version: 1.0 References: <07714a8d9583dd2ebfe548f5c066d6d2213434d7.camel@redhat.com> In-Reply-To: <07714a8d9583dd2ebfe548f5c066d6d2213434d7.camel@redhat.com> From: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= Date: Sat, 18 Dec 2021 20:36:26 +0100 Message-ID: Subject: Re: Memory leaks (detected by Valgrind) To: David Malcolm Cc: =?UTF-8?Q?Marc_Nieper=2DWi=C3=9Fkirchen?= , Alex Coplan , Mark Wielaard , "jit@gcc.gnu.org" , Joseph Myers Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: jit@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Jit mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Dec 2021 19:36:41 -0000 Am Sa., 18. Dez. 2021 um 17:45 Uhr schrieb David Malcolm : [...] > IIRC I tried that approach, and the maintainer (Joseph Myers, I think), > wasn't keen on it, but this was a few years ago. I've tried finding > the discussion in the archives, but couldn't. IIRC, he preferred > adding a flag to strings in gcc.c, tracking if they needed to be freed. > I'm CCing Joseph. FWIW there's a class in libcpp/include/line-map.h: > class label_text which does this. Perhaps it could be used for this > (and maybe renamed???) Using label_text (suitably renamed) everywhere looks like the most elegant solution but it would be a very invasive change to the existing code of gcc.c. It contains and uses a lot of functions that handle strings and allocate new ones (like find_file or concat), which would have to be rewritten to take a label_text argument. A much simpler solution is IMO to maintain a vector of pointers that have to be eventually freed. A function template T *gc (T *s) adds the argument to the vector of addresses to be garbage-collected (= freed) later. Many calls to, say, concat would then be rewritten in the form gc (concat (...)) Marc