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

From: Justin P. Mattock
Date: Wed Nov 04 2009 - 15:39:04 EST

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?


Not sure how to use these.(need to read)
Any quick commands I can do to get the info
to you?

Justin P. Mattock
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