From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932459AbZKDUiy (ORCPT ); Wed, 4 Nov 2009 15:38:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757271AbZKDUix (ORCPT ); Wed, 4 Nov 2009 15:38:53 -0500 Received: from mail-bw0-f227.google.com ([209.85.218.227]:36803 "EHLO mail-bw0-f227.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756844AbZKDUiw (ORCPT ); Wed, 4 Nov 2009 15:38:52 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xDuRVTfwcIrTMZsOaEy2MSWIrLIf38skwjdEu607B3zb3b8axcLuG3EdgSknhniSvh CrXGCIuyG+XGGjQV/vMNPiYze3zLFiq/vbqkR+sfI9IbgOMOJjqK1P7cMnXbLzTWL8oC sgBB8n3wIM1sdYav5/BDhi/1dbTx8Xx9+r63A= Message-ID: <4AF1E66D.6060705@gmail.com> Date: Wed, 04 Nov 2009 12:39:09 -0800 From: "Justin P. Mattock" User-Agent: Spicebird/0.7.1 (X11; 2009022519) MIME-Version: 1.0 To: Dave Korn CC: Andrew Morton , Linux Kernel Mailing List , gcc@gcc.gnu.org, KOSAKI Motohiro , David Rientjes Subject: Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0 References: <20091103222432.4a94bd8f.akpm@linux-foundation.org> <4AF17DED.7080808@gmail.com> <4AF198E1.9010303@gmail.com> <4AF1A198.1090709@gmail.com> <4AF1DA8D.9070009@gmail.com> In-Reply-To: <4AF1DA8D.9070009@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Dave Korn wrote: > Justin Mattock wrote: > > >> O.k. here is the info from dmesg(with the patch added) >> and what -fmem-report: >> > > I don't know how to read the oom dmesg, but as to the -fmem-report: > > >> Memory still allocated at the end of the compilation process >> Size Allocated Used Overhead >> Total 7200k 5293k 104k >> > > ... what that's telling us is that there isn't a substantial leak in GCC, as > there's only 7 meg left unreclaimed by GC at the end. I think we'll have to > wait and see what the debugger tells us; either GCC really is using that much > memory in processing the file, or there's some kind of system or kernel bug > you're running into that is causing a leak in the VMM rather than the application. > > just finished compiling and installing gdb/valgrind >> String pool >> > > >> bytes 86k (17592186044415M overhead) >> > > 0xFFFFFFFFFFF00000, lol, wut? It's possible that indicates some sort of > memory corruption going on. Maybe valgrind can help, do you have that? > > cheers, > DaveK > > > Not sure how to use these.(need to read) Any quick commands I can do to get the info to you? Justin P. Mattock