[Bug 714921] Re: gcc-linaro uses an unreasonable amount of memory to compile qemu on armel

[Bug Watch Updater]

** Changed in: gcc-4.5 (Debian)
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-4.5 in Ubuntu.
https://bugs.launchpad.net/bugs/714921

Title:
  gcc-linaro uses an unreasonable amount of memory to compile qemu on
  armel

Status in Linaro GCC:
  Fix Released
Status in “gcc-4.5” package in Ubuntu:
  Fix Released
Status in “gcc-4.5” package in Debian:
  Fix Released

Bug description:
  I've been trying to sort out why qemu-linaro was failing to build on
  armel; the build logs have been showing unreasonable memory
  consumption - e.g., an OOM on a buildd with 30GB of swap.  The same
  build did not run out of memory with gcc-4.4 on armel (I can reliably
  build the same code with ulimit -S -v $((1024*1024)) using gcc-4.4);
  it does not run out of memory when using the *same* gcc-4.5 as an
  x86->armel cross-compiler (requires a ulimit of 3250MiB in my tests);
  and it does not run out of memory on armel with gcc-4.5 if I pass
  -fno-var-tracking (completes with a ulimit of 320MiB).

  But if I build with -O2 -g natively on armel and leave var-tracking
  on, it OOMs even with a ulimit of 5GiB.

  This is more than a 16-fold increase in memory consumption from var
  tracking.  Furthermore, the memory usage seems to show a dramatic
  spike right before the failure.  Here's the memory usage immediately
  before the OOM:

  # free
               total       used       free     shared    buffers     cached
  Mem:        496996     456488      40508          0        172       7616
  -/+ buffers/cache:     448700      48296
  Swap:      6032396    1411232    4621164
  # ps u 2642
  USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
  root      2642 15.3 81.9 1615736 407472 ttyO2  T    22:40  11:00 /usr/lib/gcc/ar
  # 

  This is 23 minutes into the build.  But with a ulimit of 5GiB, within
  seconds I get the inevitable:

  virtual memory exhausted: Cannot allocate memory

  This is sudden enough that I'm convinced there's some kind of bug
  here; I can't imagine why gcc should need to allocate > 3GB of memory
  at a go.

  I'll post a copy shortly of the preprocessed source used to reproduce
  this, plus the commandline that triggers it.  I'll also see what I can
  root out with valgrind and/or strace; though at 24minutes an iteration
  it'll take a while yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc-linaro/+bug/714921/+subscriptions