From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 802 invoked by alias); 29 Nov 2012 12:02:12 -0000 Received: (qmail 778 invoked by uid 22791); 29 Nov 2012 12:02:11 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 12:02:02 +0000 Received: by mail-la0-f47.google.com with SMTP id u2so11501224lag.20 for ; Thu, 29 Nov 2012 04:02:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.37.101 with SMTP id x5mr3982884lbj.36.1354190520549; Thu, 29 Nov 2012 04:02:00 -0800 (PST) Received: by 10.152.133.4 with HTTP; Thu, 29 Nov 2012 04:02:00 -0800 (PST) In-Reply-To: <50B7492B.5030702@net-b.de> References: <50B39C70.9010304@net-b.de> <50B7492B.5030702@net-b.de> Date: Thu, 29 Nov 2012 12:02:00 -0000 Message-ID: Subject: Re: [Patch, Fortran] PR55469 - fix I/O memory leaks in case of failure and iostat= being present From: Janne Blomqvist To: Tobias Burnus Cc: gcc patches , gfortran , Jerry DeLisle Content-Type: text/plain; charset=UTF-8 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg02410.txt.bz2 On Thu, Nov 29, 2012 at 1:38 PM, Tobias Burnus wrote: > Tobias Burnus wrote: >> >> l_push_char allocates memory which is freed with free_line. However, >> currently, the memory is not always freed when calling generate_error. If >> one aborts, that's fine. However, generate_error can also set the iostat >> variable. > > > Updated version: Corrected PR number - and ensured that if convert_real > fails, free_saved is called (cf. additional test case in the PR). > > Build and regtested on x86-64-gnu-linux. > OK for the trunk? IIRC this is supposed to be a cache than can be subsequently reused without freeing and allocating it again. So it might be better to free it once when the unit is closed. At some point this line buffer should be removed completely and replaced with the fbuf_*() machinery. But so far nobody has found the time to work on that. -- Janne Blomqvist