From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jit-return-398-listarch-jit=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 21489 invoked by alias); 19 Nov 2014 16:59:54 -0000
Mailing-List: contact jit-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:jit@gcc.gnu.org>
List-Help: <mailto:jit-help@gcc.gnu.org>
List-Subscribe: <mailto:jit-subscribe@gcc.gnu.org>
Sender: jit-owner@gcc.gnu.org
Received: (qmail 21465 invoked by uid 89); 19 Nov 2014 16:59:54 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.98.4 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level: 
X-Spam-User: qpsmtpd, 2 recipients
X-HELO: mx1.redhat.com
Message-ID: <546CCC86.8020305@redhat.com>
Date: Wed, 01 Jan 2014 00:00:00 -0000
From: Jeff Law <law@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: David Malcolm <dmalcolm@redhat.com>, gcc-patches@gcc.gnu.org,
        jit@gcc.gnu.org
Subject: Re: [PATCH 10/21] PR jit/63854: Fix leak of worklist within jit-recording.c
References: <1416393981-39626-1-git-send-email-dmalcolm@redhat.com> <1416393981-39626-11-git-send-email-dmalcolm@redhat.com>
In-Reply-To: <1416393981-39626-11-git-send-email-dmalcolm@redhat.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-SW-Source: 2014-q4/txt/msg00183.txt.bz2

On 11/19/14 03:46, David Malcolm wrote:
> Fix this leak:
>
> 160 bytes in 5 blocks are definitely lost in loss record 154 of 228
>     at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
>     by 0x5D75D4F: xrealloc (xmalloc.c:177)
>     by 0x4DE1710: void va_heap::reserve<gcc::jit::recording::block*>(vec<gcc::jit::recording::block*, va_heap, vl_embed>*&, unsigned int, bool) (vec.h:310)
>     by 0x4DDFAB5: vec<gcc::jit::recording::block*, va_heap, vl_ptr>::reserve(unsigned int, bool) (vec.h:1428)
>     by 0x4DDFBFC: vec<gcc::jit::recording::block*, va_heap, vl_ptr>::reserve_exact(unsigned int) (vec.h:1448)
>     by 0x4DDE588: vec<gcc::jit::recording::block*, va_heap, vl_ptr>::create(unsigned int) (vec.h:1463)
>     by 0x4DD9B9F: gcc::jit::recording::function::validate() (jit-recording.c:2191)
>     by 0x4DD7AD3: gcc::jit::recording::context::validate() (jit-recording.c:1005)
>     by 0x4DD7660: gcc::jit::recording::context::compile() (jit-recording.c:848)
>     by 0x4DD5BD2: gcc_jit_context_compile (libgccjit.c:2014)
>     by 0x401CA4: test_jit (harness.h:190)
>     by 0x401D88: main (harness.h:232)
>
> gcc/jit/ChangeLog:
> 	PR jit/63854
> 	* jit-recording.c (recording::function::validate): Convert
> 	"worklist" from vec<> to autovec<> to fix a leak.
JIT space, yours to approve :-)  We haven't formalized that yet, but 
it'd be silly to do anything else.

Anyway so formally, this is OK for the trunk.

jeff