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

From: Dave Korn
Date: Wed Nov 04 2009 - 14:33:18 EST

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.

> 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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at