app-office/openoffice-2.0.3 claims at the beginning of the build that it requires 256 MiB of memory in order to compile, yet it crashed with "virtual memory exhausted: Cannot allocate memory" in a build environment where it had 300. Originally, it had 504736k (and 1052212k swap) to play with, but it locked up my machine twice by sucking up all the memory, so I had limited it with `ulimit -v 307200` before retrying the build. Then it died with this: ----- Making: ../../../../unxlngi6.pro/slo/SlideSorterView.obj g++ -Wreturn-type -fmessage-length=0 -c -I. -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/offuh -I../inc -I../../inc -I../../../../inc -I../../../../unx/inc -I../../../../unxlngi6.pro/inc -I. -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/external -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/unxlngi6/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/res -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/inc/Xp31 -INO_JAVA_HOME/include -INO_JAVA_HOME/include/linux -INO_JAVA_HOME/include/native_threads/include -I/usr/include -I. -I../../../../res -I. -Os -fno-strict-aliasing -Wuninitialized -fvisibility=hidden -pipe -O2 -march=pentium4 -mno-tls-direct-seg-refs -pipe -Wno-ctor-dtor-privacy -fvisibility-inlines-hidden -fexceptions -fno-enforce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DINTEL -DCVER=C341 -D_USE_NAMESPACE -DNPTL -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DOOC680=OOC680 -DSD_DLLIMPLEMENTATION -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../../../unxlngi6.pro/slo/SlideSorterView.o /var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/sd/source/ui/slidesorter/view/SlideSorterView.cxx virtual memory exhausted: Cannot allocate memory dmake: Error code 1, while making '../../../../unxlngi6.pro/slo/SlideSorterView.obj' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/sd/source/ui/slidesorter/view make: *** [stamp/build] Error 1 !!! ERROR: app-office/openoffice-2.0.3 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile openoffice-2.0.3.ebuild, line 251: Called die ----- Portage 2.1-r1 (default-linux/x86/2005.1, gcc-3.4.6, glibc-2.3.6-r4, 2.6.15-gentoo-r1 i686) ================================================================= System uname: 2.6.15-gentoo-r1 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.6.15 app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -mno-tls-direct-seg-refs -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=pentium4 -mno-tls-direct-seg-refs -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.utf8" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib adns alsa apm avi bash-completion berkdb bitmap-fonts boundschecking bzip2 caps cjk cli crypt cscope cups curl dlloader doc dri emboss encode examples exif firefox foomaticdb fortran gd gdbm gif gmp gpm gstreamer gtk gtk2 iconv idn imap imlib isdnlog jpeg jpeg2k kerberos ldap libg++ libwww mad mailwrapper mbox mikmod mng mp3 mpeg mysql ncurses nls nptl objc ogg oggvorbis opengl oss pam pcre pdflib perl png pop pppd python qt4 quicktime readline real reflection ruby samba sasl sdl session speex spell spl ssl svg tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode urandom vorbis xml xml2 xmms xorg xpm xsl xv zip zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
I see this too. During the building of openoffice-2.0.3 it consumes all my memory and then all my swap space (half gig of each) before failing.
Note that the lockups I was experiencing are not OOo-specific; that seems to be happening whenever any single process sucks up 100% of real memory and swap is encrypted; disabling encryption allowed hefty processes to start filling up swap normally. I was able to build OOo today by doing as such, but it took all my RAM (504736k) and a good chunk of swap to do so. If there's something I can pass to emerge to make it log memory usage for each build step, I'm willing to rebuild and pass the logs to the appropriate developer.
I monitored memory usage while emergeing openoffice-2.0.3 and found that my swap memory was never more than 1/3 used for seven hours, until it reached the SlideSorterView.cxx stage described above, when suddenly the useage went up to 100% and the ebuild failed.
I have a machine with 512MiB of real RAM and I have raised the swap up to 7GiB, I still can't compile it: # swapon -s Filename Type Size Used Priority /dev/ide/host0/bus0/target0/lun0/part2 partition 996020 4 -5 /SWAPFILE file 2097144 0 -4 /SWAPFILE2 file 4194296 38360 -3 # free total used free shared buffers cached Mem: 515828 514132 1696 0 431896 19244 -/+ buffers/cache: 62992 452836 Swap: 7287460 38364 7249096 The last lines of the compile are: Making: ../../../../unxlngi6.pro/slo/SlideSorterView.obj g++ -Wreturn-type -fmessage-length=0 -c -I. -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/offuh -I../inc -I../../inc -I../../../../inc -I../../../../unx/inc -I../../../../unxlngi6.pro/inc -I. -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/external -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/unxlngi6/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/res -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/inc/Xp31 -I/opt/sun-jdk-1.4.2.10/include -I/opt/sun-jdk-1.4.2.10/include/linux -I/opt/sun-jdk-1.4.2.10/include/native_threads/include -I/usr/include -I. -I../../../../res -I.-Os -fno-strict-aliasing -Wuninitialized -fvisibility=hidden -pipe -O2 -march=athlon-xp -pipe -Wno-ctor-dtor-privacy -fvisibility-inlines-hidden -fexceptions-fno-enforce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DINTEL -DCVER=C341 -D_USE_NAMESPACE -DNPTL -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR-D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DOOC680=OOC680 -DSD_DLLIMPLEMENTATION -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../../../unxlngi6.pro/slo/SlideSorterView.o /var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/sd/source/ui/slidesorter/view/SlideSorterView.cxx g++: Error interno: `Terminado' (programa cc1plus) Por favor env
I have a machine with 512MiB of real RAM and I have raised the swap up to 7GiB, I still can't compile it: # swapon -s Filename Type Size Used Priority /dev/ide/host0/bus0/target0/lun0/part2 partition 996020 4 -5 /SWAPFILE file 2097144 0 -4 /SWAPFILE2 file 4194296 38360 -3 # free total used free shared buffers cached Mem: 515828 514132 1696 0 431896 19244 -/+ buffers/cache: 62992 452836 Swap: 7287460 38364 7249096 The last lines of the compile are: Making: ../../../../unxlngi6.pro/slo/SlideSorterView.obj g++ -Wreturn-type -fmessage-length=0 -c -I. -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/offuh -I../inc -I../../inc -I../../../../inc -I../../../../unx/inc -I../../../../unxlngi6.pro/inc -I. -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/external -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/unxlngi6/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/inc -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/res -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solver/680/unxlngi6.pro/inc/stl -I/var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/solenv/inc/Xp31 -I/opt/sun-jdk-1.4.2.10/include -I/opt/sun-jdk-1.4.2.10/include/linux -I/opt/sun-jdk-1.4.2.10/include/native_threads/include -I/usr/include -I. -I../../../../res -I.-Os -fno-strict-aliasing -Wuninitialized -fvisibility=hidden -pipe -O2 -march=athlon-xp -pipe -Wno-ctor-dtor-privacy -fvisibility-inlines-hidden -fexceptions-fno-enforce-eh-specs -fpic -DLINUX -DUNX -DVCL -DGCC -DC341 -DINTEL -DCVER=C341 -D_USE_NAMESPACE -DNPTL -DGLIBC=2 -DX86 -D_PTHREADS -D_REENTRANT -DNEW_SOLAR-D_USE_NAMESPACE=1 -DSTLPORT_VERSION=400 -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/lib/gcc/i686-pc-linux-gnu/3.4.6/include/g++-v3 -DSUPD=680 -DPRODUCT -DNDEBUG -DPRODUCT_FULL -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DEXCEPTIONS_ON -DCUI -DSOLAR_JAVA -DOOC680=OOC680 -DSD_DLLIMPLEMENTATION -DSHAREDLIB -D_DLL_ -DMULTITHREAD -o ../../../../unxlngi6.pro/slo/SlideSorterView.o /var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/sd/source/ui/slidesorter/view/SlideSorterView.cxx g++: Error interno: `Terminado' (programa cc1plus) Por favor envíe un reporte completo de error. Vea <URL:http://bugs.gentoo.org/> para más instrucciones. dmake: Error code 1, while making '../../../../unxlngi6.pro/slo/SlideSorterView.obj' '---* tg_merge.mk *---' ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-2.0.3/work/ooo-build-2.0.3.0/build/OOO_2_0_3/sd/source/ui/slidesorter/view make: *** [stamp/build] Error 1 !!! ERROR: app-office/openoffice-2.0.3 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile openoffice-2.0.3.ebuild, line 251: Called die !!! Build failed !!! If you need support, post the topmost build error, and the call stack if relevant. and the output of dmesg: oom-killer: gfp_mask=0x1d2 DMA per-cpu: cpu 0 hot: low 2, high 6, batch 1 cpu 0 cold: low 0, high 2, batch 1 Normal per-cpu: cpu 0 hot: low 32, high 96, batch 16 cpu 0 cold: low 0, high 32, batch 16 HighMem per-cpu: empty Free pages: 676kB (0kB HighMem) Active:123393 inactive:366 dirty:0 writeback:2 unstable:0 free:169 slab:2486 map ped:123226 pagetables:495 DMA free:20kB min:20kB low:40kB high:60kB active:12256kB inactive:40kB present:1 6384kB protections[]: 0 0 0 Normal free:656kB min:700kB low:1400kB high:2100kB active:481316kB inactive:1424 kB present:507888kB protections[]: 0 0 0 HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present: 0kB protections[]: 0 0 0 DMA: 1*4kB 0*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 20kB Normal: 0*4kB 0*8kB 1*16kB 0*32kB 0*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048 kB 0*4096kB = 656kB HighMem: empty Swap cache: add 1493814, delete 1465799, find 283502/358604, race 9+19 Out of Memory: Killed process 21434 (cc1plus). The kernel is : # uname -a Linux sesion-esind 2.6.9 #2 Fri Nov 5 01:16:55 CET 2004 i686 AMD Athlon(TM) XP 2600+ GNU/Linux Now relevant emerge --info: Gentoo Base System version 1.6.15 Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.9 i686) ================================================================= System uname: 2.6.9 i686 AMD Athlon(TM) XP 2600+ app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -ftracer -fprefetch-loop-arrays -pipe" CHOST="i686-pc-linux-gnu" CXXFLAGS="-O2 -march=athlon-xp -ftracer -fprefetch-loop-arrays -pipe" FEATURES="autoconfig distlocks fixpackages metadata-transfer parallel-fetch sand box sfperms strict" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/d istfiles' --exclude='/local' --exclude='/packages'" BTW, a quick way to add 4GiB of swap: # dd if=/dev/zero of=/SWAPFILE2 bs=1M count=4096 ; mkswap /SWAPFILE2 ; swapon /SWAPFILE2 Check with swapon -s.
It's failing for me in the same place. I'm compiling with a symlink /var/tmp -> /tmp and a tmpfs mounted on /tmp. After it crashes here's my df -h: Filesystem Size Used Avail Use% Mounted on none 4.9G 2.8G 2.2G 56% /tmp I looked in dmesg and found oom-killer output: oom-killer: gfp_mask=0xd0, order=0 [<c0103f10>] show_trace+0x20/0x30 [<c010404e>] dump_stack+0x1e/0x20 [<c0141d78>] out_of_memory+0xa8/0x110 [<c0143081>] __alloc_pages+0x2d1/0x300 [<c01430d1>] __get_free_pages+0x21/0x50 [<c0173b1a>] __pollwait+0x3a/0xc0 [<c0357b20>] unix_poll+0xb0/0xc0 [<c02f8b71>] sock_poll+0x21/0x30 [<c01747c3>] do_pollfd+0x93/0xa0 [<c017482f>] do_poll+0x5f/0x120 [<c0174a7d>] do_sys_poll+0x18d/0x200 [<c0174b2a>] sys_poll+0x3a/0x70 [<c01030fb>] sysenter_past_esp+0x54/0x75 Mem-info: DMA per-cpu: cpu 0 hot: high 0, batch 1 used:0 cpu 0 cold: high 0, batch 1 used:0 DMA32 per-cpu: empty Normal per-cpu: cpu 0 hot: high 186, batch 31 used:25 cpu 0 cold: high 62, batch 15 used:55 HighMem per-cpu: empty Free pages: 5704kB (0kB HighMem) Active:74461 inactive:15339 dirty:0 writeback:386 unstable:0 free:1426 slab:27888 mapped:89363 pagetables:241 DMA free:2068kB min:88kB low:108kB high:132kB active:7396kB inactive:0kB present:16384kB pages_scanned:7444 all_unreclaimable? yes lowmem_reserve[]: 0 0 495 495 DMA32 free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 495 495 Normal free:3636kB min:2804kB low:3504kB high:4204kB active:290448kB inactive:61356kB present:507840kB pages_scanned:148 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 HighMem free:0kB min:128kB low:128kB high:128kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 DMA: 1*4kB 0*8kB 1*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 2068kB DMA32: empty Normal: 209*4kB 16*8kB 1*16kB 1*32kB 3*64kB 1*128kB 1*256kB 0*512kB 0*1024kB 1*2048kB 0*4096kB = 3636kB HighMem: empty Swap cache: add 3408059, delete 3407425, find 700662/841684, race 0+0 Free swap = 3460416kB Total swap = 6490188kB Free swap: 3460416kB 131056 pages of RAM 0 pages of HIGHMEM 2326 reserved pages 483 pages shared 602 pages swap cached 0 pages dirty 193 pages writeback 89267 pages mapped 27888 pages slab 241 pages pagetables Out of Memory: Kill process 30312 (cc1plus) score 17541 and children. Out of memory: Killed process 30312 (cc1plus). Note that it says that "free swap" is 3460416kB. Clearly between this and df, I'm not out of swap. It's out of "HIGHMEM" however. This sounds like it could be a kernel issue. -------------------- Portage 2.1-r1 (default-linux/x86/2006.0, gcc-3.4.6, glibc-2.3.6-r4, 2.6.16-gentoo-r11 i686) ================================================================= System uname: 2.6.16-gentoo-r11 i686 AMD Athlon(tm) XP 2500+ Gentoo Base System version 1.6.15 ccache version 2.3 [disabled] app-admin/eselect-compiler: [Not Present] dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.3 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-pipe -O2 -march=athlon-xp -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-pipe -O2 -march=athlon-xp -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer parallel-fetch sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.acm.cs.rpi.edu/gentoo http://distro.ibiblio.org/pub/Linux/distributions/gentoo" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X aac acpi alsa apache2 apm avi bash-completion berkdb bitmap-fonts bzlib cli crypt cups dlloader dri eds emboss esd foomaticdb fortran gb gdbm gif gnome gpm gstreamer gtk gtk2 imlib ipv6 isdnlog jpeg libg++ libwww mad maildir matrox mbox memlimit mikmod mmx mmx2 mp3 mpeg ncurses nls nptl ofx ogg opengl oss pam pcntl pcre pdflib perl pic png posix ppds pppd prelude python qt3 qt4 quicktime readline reflection sdl session spell spl sse ssl svg tcpd theora truetype truetype-fonts type1-fonts udev unicode videos vorbis xml xmms xorg xprint xv zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_mga video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Just realized that "highmem" refers to >= 1GB of system RAM. I'm at 512MB so that *should* be zero. Duh.
I managed to compile it, I had to add more swap AND echo 1 > /proc/sys/vm/overcommit_memory, /usr/src/linux/Documentation/sysctl/vm.txt: overcommit_memory: This value contains a flag that enables memory overcommitment. When this flag is 0, the kernel attempts to estimate the amount of free memory left when userspace requests more memory. When this flag is 1, the kernel pretends there is always enough memory until it actually runs out. When this flag is 2, the kernel uses a "never overcommit" policy that attempts to prevent any overcommit of memory. This feature can be very useful because there are a lot of programs that malloc() huge amounts of memory "just-in-case" and don't use much of it. The default value is 0. See Documentation/vm/overcommit-accounting and security/commoncap.c::cap_vm_enough_memory() for more information. The peak usage of swap was: total used free shared buffers cached Mem: 515828 511200 4628 0 4208 43232 -/+ buffers/cache: 463760 52068 Swap: 7287460 776672 6510788 So it can be done once you provide enough swap AND remember to permit overcommit.
(In reply to comment #7) > I managed to compile it, I had to add more swap AND echo 1 > > /proc/sys/vm/overcommit_memory, OK, will try this myself soon. Should have plenty of swap but the overcommit bit is new. Strange that it needs it now but didn't before. > The peak usage of swap was: > total used free shared buffers cached > Mem: 515828 511200 4628 0 4208 43232 > -/+ buffers/cache: 463760 52068 > Swap: 7287460 776672 6510788 What command did you use for this output? Neither cat /proc/swaps nor ps nor top look like that...
That looks like the output of /usr/bin/free.
Setting overcommit_memory to 1 got it to complete successfully, with no increase in available swap. The output of free if you're interested (remember, I use tmpfs), right before it started merging to the live filesystem: total used free shared buffers cached Mem: 515496 509064 6432 0 1944 125144 -/+ buffers/cache: 381976 133520 Swap: 6490188 3955176 2535012 Has OO.o changed *that* dramatically between 2.0.2-r* and 2.0.3 that this kernel tweak is suddenly necessary? Or was it really a good idea/a requirement the whole time and it never bit us before? (Somebody want to change the Bugzilla "Summary" line?...)
Just FYI I'm using kernel 2.6.9 and I'm beginning to suspect that there could be a bug in the overcommit accounting. The default value for /proc/sys/vm/overcommit_memory is 0 the meaning of 0 is: Documentation/sysctl/vm.txt: When this flag is 0, the kernel attempts to estimate the amount of free memory left when userspace requests more memory. Documentation/vm/overcommit-accounting: 0 - Heuristic overcommit handling. Obvious overcommits of address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to allocate slighly more memory in this mode. This is the default. I have tried to compile OO.o with over 7GiB of swap, obviously I was not overcomminting memory, and it failed. I think swap is part of the avaliable memory, but it seems to be different.
*** Bug 145030 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > It's failing for me in the same place. I'm compiling with a symlink /var/tmp > -> /tmp and a tmpfs mounted on /tmp. An openoffice build puts about 5GB in /var/tmp/portage, so if that resides in memory you'll need 5GB of physical memory (tmpfs doesn't swap). Plese edit /etc/make.conf and set PORTAGE_TMPDIR to something resideing on a harddrive. Plese note bug #130837 when setting PORTAGE_TMPDIR though, openoffice-2.0.3 will break if PORTAGE_TMPDIR is longer than 11 characters (2.0.4_rc1 has a workaround to work with up to 25 characters in PORTAGE_TMPDIR).
(In reply to comment #13) > An openoffice build puts about 5GB in /var/tmp/portage, so if that resides in > memory you'll need 5GB of physical memory (tmpfs doesn't swap). Um, yes it does...
From my point of view it can't have anything to do with openoffice itself or the ebuild. I'm having 256 MB physical memory and a 1 GB swap partition on an Athlon XP 1600+. Just to be sure I stop the biggest programs like X (KDE), privoxy etc. what I don't need during the OOo compilation before the installation. So I'm having less than 256 MB free memory and not the fastest CPU. And I don't have any problems with compiling openoffice. For me openoffice compiles perfectly. It only needs as known and expected 11 or 12 hours to compile.
I have 512MB RAM, and it (usually) compiles fine. Ok, today it fails because of libc. My 512 RAM are usually enough, even when X+TB+FF+ other X apps are open; just takes 12h on mt Athlon 1600. But, my swap is 2G !!! I never took care how much it uses swap. Usually, as non comiling desktop, with daily reboot, I need 50M to 200M swap. When emerging, I can use 300 to 600M. but my tip of the day is to remind happy owners of 64b CPUs that when comparing RAM volumes, they should devide theirs by TWO !!! Because of 64b arch, a machine with 512M RAM should be compared with only 256M on x86/32b !!! I have no clue how things like selinux, ulimit, xen, vmware, sandbox ... handle this problem. But please keep this in mind !!! 512 on 64b is less than 512 on 32b ! Thus, if maintainer says you need 256MiB when he made the test on 32b, this is VERY LIKELY not to suffice on 64b machines !
Please test again with a recent OOo. It may have been fixed by the mean time.
(In reply to comment #6) Don't clutter this bugs about comments on lack of memory with /var/tmp/portage in tmpfs. That's just completely crazy for openoffice and we don't care. For the rest of this bug - get yourself a bigger swap or don't compile this if you are short of RAM.
The problem that most of the commenters here (including myself) were pointing out is that, however we were trying to compile it, what had worked fine before suddenly stopped working with this version. The overcommit memory tweak that Jorge pointed got it to work for me last time. So the immediate problem is solved, though my question in comment #11 still holds. I haven't recompiled OO.o since then. I'll try it again on 2.1 without that tweak in the near future to see if it behaves like < 2.0.3 did.
Cloasin a not particularly productive bug; yeah it needs tons of RAM, live with it or use -bin.
