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

[Jiri Slaby]

On 11/02/2009 10:29 PM, Justin Mattock wrote:
> [  532.942324] cc1plus invoked oom-killer: gfp_mask=0x280da, order=0, 
> oom_adj=0
> [  532.942330] Pid: 16002, comm: cc1plus Tainted: P
> 2.6.32-rc5-00083-g04ea458 #2
> [  532.942333] Call Trace:
> [  532.942342]  [] T.417+0x7c/0x245
> [  532.942347]  [] __out_of_memory+0x142/0x159
> [  532.942352]  [] out_of_memory+0x6e/0x9d
> [  532.942357]  [] __alloc_pages_nodemask+0x47e/0x5cc
> [  532.942363]  [] handle_mm_fault+0x25d/0x68e
> [  532.942369]  [] do_page_fault+0x2bb/0x2d3
> [  532.942373]  [] page_fault+0x25/0x30
...
> [  532.957951] Out of memory: kill process 16001 (c++) score 543727 or a child
> [  532.957955] Killed process 16002 (cc1plus)
> 
> I just compiled the latest gcc snapshot a few days
> ago.

How many jobs did you run in parallel? Was there anything else memory
consuming running on that machine? Do you run the same jobs count every
time you compile such big c++ projects?

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

[Jiri Slaby]

On 11/02/2009 11:02 PM, Justin Mattock wrote:
> Now with this oom-killer I'm
> hitting this on an imac9,1 with
> gcc (GCC) 4.5.0 20091029 (experimental)

So there is probably a leak in the gcc chain. Does this happen with a
stable gcc version?

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

[Jiri Slaby]

On 11/04/2009 07:44 AM, Justin P. Mattock wrote:
> as for compiling: libc compiled fine, kernel fine,
> and every package on the clfs list up to boot up the fresh system.

It might be pretty c++ only, I think.

Re: [BUG] pragma: attempt to use poisoned * in struct member

[Jiri Slaby]

On 11/08/2008 04:46 PM, Tom Tromey wrote:
>>>>>> "Jiri" == Jiri Slaby <[EMAIL PROTECTED]> writes:
> 
> Jiri> while compiling slightly augmented cc1, I've found a poison
> Jiri> pragma bug. Here comes a trimmed example of the bug:
> 
> Jiri> $ echo -e '#pragma GCC poison malloc\nstruct { int malloc; };'|gcc - -E 
> -o/dev/null
> Jiri> :2:14: error: attempt to use poisoned "malloc"
> 
> Could you explain what you think the bug is?

Either its use in gcc sources or the way how the #pragma keyword is handled
(this can be hardly changed).

> My first reaction is that this is not a bug.  #pragma poison works on
> identifiers, no matter what context they appear in (outside of system
> headers).  For this reason, poison is not always useful.
> __attribute__((deprecated)) might be closer to what you want, though
> it can be hard to use that with system-declared functions like malloc.

I want to extend cpp to extract some more info (for backward mapping from
preprocessed_code into source_code+line+column) into xml while preprocessing and
I use gdome2 library. If I try to compile it, it fails due to:
struct _GMemVTable
{
  gpointer (*malloc)  (gsizen_bytes);
  gpointer (*realloc) (gpointer mem,
   gsizen_bytes);
  void (*free)(gpointer mem);
  /* optional; set to NULL if not used ! */
  gpointer (*calloc)  (gsizen_blocks,


from /usr/include/glib-2.0/glib/gmem.h. If I remove this structure compeltely,
everything is OK (it's unused anyway).

At least some option to disable these pragma checks inside cpp would be great.
(I suppose there is none, I found it neither in gcc.info nor cpp.info nor
anywhere else...)

[BUG] pragma: attempt to use poisoned * in struct member

[Jiri Slaby]

Hi,

while compiling slightly augmented cc1, I've found a poison pragma bug. Here
comes a trimmed example of the bug:

$ echo -e '#pragma GCC poison malloc\nstruct { int malloc; };'|gcc - -E 
-o/dev/null
:2:14: error: attempt to use poisoned "malloc"

Re: [BUG] pragma: attempt to use poisoned * in struct member

[Jiri Slaby]

On 11/11/2008 02:00 AM, Tom Tromey wrote:
>>>>>> "Jiri" == Jiri Slaby <[EMAIL PROTECTED]> writes:
> 
> Jiri> I want to extend cpp to extract some more info (for backward
> Jiri> mapping from preprocessed_code into source_code+line+column)
> Jiri> into xml while preprocessing and I use gdome2 library. If I try
> Jiri> to compile it, it fails due to: [...]
> 
> I would suggest just dropping the #pragma poison from your gcc.
> 
> Or, I guess you could use a different XML library.

Ok, nevermind, don't bother with that.