linux-kernel - Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, oom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4AF198E1.9010303@gmail.com>
Date:	Wed, 04 Nov 2009 07:08:17 -0800
From:	"Justin P. Mattock" <justinmattock@...il.com>
To:	Dave Korn <dave.korn.cygwin@...glemail.com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	gcc@....gnu.org, KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	David Rientjes <rientjes@...washington.edu>
Subject: Re: cc1plus invoked oom-killer: gfp_mask=0x280da, order=0,  oom_adj=0

Dave Korn wrote:
> Andrew Morton wrote:
>    
>> On Mon, 2 Nov 2009 13:29:29 -0800 Justin Mattock<justinmattock@...il.com>  wrote:
>>
>>      
>>> Hello,
>>> I'm not sure how to handle this,
>>> while compiling firefox-3.6b1.source
>>> I get this with the default compiling options,
>>> as well as custom:
>>>
>>> ...
>>>
>>> active_anon:2360492kB inactive_anon:590196kB active_file:84kB
>>>        
>> 2.8GB of anonymous memory
>>
>>      
>>> [  532.942508] Free swap  = 0kB
>>> [  532.942510] Total swap = 431632kB
>>>        
>> 430MB of swap, all used up.
>>
>> That's a genuine OOM.  Something (presumably cc1plus) has consumed
>> waaaay too much memory, quite possibly leaked it.
>>
>> It would help if the oom-killer were to print some information about
>> the oom-killed process's memory footprint.
>>      
>
>    I would think that the quickest way to proceed would be to re-run the
> failing compile command under gdb at the command-line and see what it's doing
> when the oom killer signals it, wouldn't it?  Or turn up the swap until it
> doesn't get killed and see what info can be gleaned from the cc1(plus?)
> -fmem-report output.
>
>      cheers,
>        DaveK
>
>
>    
I can try, only issue I have is I don't
use a distro, so building anything requires me
to hand compile it(hopefully not difficult for gdb).

So give me some time on this and I'll see if I can get this up
and running, and add that patch to kernel then go from there.

Justin P. Mattock
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/