|
Bugzilla – Full Text Bug Listing |
| Summary: | memory leak in ld? | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Fabrizio Magni <fabrizio.magni> |
| Component: | Development | Assignee: | Andreas Schwab <schwab> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | pth |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Beta-Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Try --no-keep-memory. To be able to do it I should modify the oracle relinking script (ok, it can be done) or to create a wrapper for the ld command. Is the any better solution? Any variable I can set to force ld to use --no-keep-memory? Yes, it's called --no-keep-memory. Isn't --no-keep-memory a parameter? I mean... can I set the parameter via an env variable? If you read info '(ld)Environment' you'll see that there is no environment variable to do so. So you'll have to bite the bullet and edit Oracles relinking script. BTW, part of the problem is IMO, that the relinking script pulls in the same libraries multiple times, which is just waste of time and memory. Opted for a wrapper. The linux box is still relinking at the moment and the ld process is increasing its size (now almost 140M). Last time it took hours (I let the relinking go for the whole night). Relinking accomplished... This time it took only 15 minutes. I'm trying without --no-keep-memory and it is taking ages aven if the memory utilization is almost the same (VIRT is 30% bigger, while RES seems 15% less). The oracle script should be fixed not to pass so many useless libraries. |
Trying to install oracle RDBMS on a compaq EVO (pentium 4) with 256M of RAM. linux:~ # uname -a Linux linux 2.6.13-rc6-git7-3-default #1 Mon Aug 15 18:28:43 UTC 2005 i686 i686 i386 GNU/Linux linux:~ # gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --enable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux Thread model: posix gcc version 4.0.2 20050812 (prerelease) (SUSE Linux) Same installation didn't give problem on SUSE 9.2. On SUSE 10, during relinking phase, the ld is growing far behind 100M. Here is the command: /usr/lib/gcc/i586-suse-linux/4.0.2/../../../../i586-suse-linux/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o /u01/app/oracle/product/10.2/db_1/rdbms/lib/oracle /usr/lib/gcc/i586-suse-linux/4.0.2/../../../crt1.o /usr/lib/gcc/i586-suse-linux/4.0.2/../../../crti.o /usr/lib/gcc/i586-suse-linux/4.0.2/crtbegin.o -L/u01/app/oracle/product/10.2/db_1/rdbms/lib/ -L/u01/app/oracle/product/10.2/db_1/lib/ -L/u01/app/oracle/product/10.2/db_1/lib/stubs/ -L/usr/lib -L/u01/app/oracle/product/10.2/db_1/lib -L/usr/lib/gcc/i586-suse-linux/4.0.2 -L/usr/lib/gcc/i586-suse-linux/4.0.2 -L/usr/lib/gcc/i586-suse-linux/4.0.2/../../../../i586-suse-linux/lib -L/usr/lib/gcc/i586-suse-linux/4.0.2/../../.. -lirc -E /u01/app/oracle/product/10.2/db_1/rdbms/lib/opimai.o /u01/app/oracle/product/10.2/db_1/rdbms/lib/ssoraed.o /u01/app/oracle/product/10.2/db_1/rdbms/lib/ttcsoi.o /u01/app/oracle/product/10.2/db_1/rdbms/lib/defopt.o --whole-archive -lperfsrv10 --no-whole-archive /u01/app/oracle/product/10.2/db_1/lib/nautab.o /u01/app/oracle/product/10.2/db_1/lib/naeet.o /u01/app/oracle/product/10.2/db_1/lib/naect.o /u01/app/oracle/product/10.2/db_1/lib/naedhs.o /u01/app/oracle/product/10.2/db_1/rdbms/lib/config.o -lserver10 -lodm10 -lnnet10 -lskgxp10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lxml10 -lcore10 -lunls10 -lsnls10 -lnls10 -lcore10 -lnls10 -lhasgen10 -lcore10 -lskgxn2 -locr10 -locrb10 -locrutl10 -lhasgen10 -lcore10 -lskgxn2 -lclient10 -lvsn10 -lcommon10 -lgeneric10 -lknlopt -loraolap10 -lslax10 -lpls10 -lplp10 -lserver10 -lclient10 -lvsn10 -lcommon10 -lgeneric10 -lknlopt -lslax10 -lpls10 -lplp10 -ljox10 -lserver10 -lclsra10 -ldbcfg10 -locijdbcst10 -lwwg -lnbeq10 -lnhost10 -lnus10 -lnldap10 -lldapclnt10 -lnsslb10 -lntcp10 -lntcps10 -lnsslb10 -lntcp10 -lntns10 -lnsslb10 -lncrypt10 -lnsgr10 -lnzjs10 -ln10 -lnnz10 -lnl10 -lnro10 -lnbeq10 -lnhost10 -lnus10 -lnldap10 -lldapclnt10 -lnsslb10 -lntcp10 -lntcps10 -lnsslb10 -lntcp10 -lntns10 -lnsslb10 -lncrypt10 -lnsgr10 -lnzjs10 -ln10 -lnnz10 -lnl10 -lmm -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lxml10 -lcore10 -lunls10 -lsnls10 -lnls10 -lcore10 -lnls10 -lnbeq10 -lnhost10 -lnus10 -lnldap10 -lldapclnt10 -lnsslb10 -lntcp10 -lntcps10 -lnsslb10 -lntcp10 -lntns10 -lnsslb10 -lncrypt10 -lnsgr10 -lnzjs10 -ln10 -lnnz10 -lnl10 -lnro10 -lnbeq10 -lnhost10 -lnus10 -lnldap10 -lldapclnt10 -lnsslb10 -lntcp10 -lntcps10 -lnsslb10 -lntcp10 -lntns10 -lnsslb10 -lncrypt10 -lnsgr10 -lnzjs10 -ln10 -lnnz10 -lnl10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lxml10 -lcore10 -lunls10 -lsnls10 -lnls10 -lcore10 -lnls10 -lordsdo10 -lctxc10 -lctx10 -lzx10 -lgx10 -lctx10 -lzx10 -lgx10 -lordimt10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lxml10 -lcore10 -lunls10 -lsnls10 -lnls10 -lcore10 -lnls10 -lsnls10 -lunls10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lcore10 -lsnls10 -lnls10 -lxml10 -lcore10 -lunls10 -lsnls10 -lnls10 -lcore10 -lnls10 -laio -ldl -lm -lpthread -lnsl -lirc -rpath /u01/app/oracle/product/10.2/db_1/lib -lm -ldl -lm -lpthread -lnsl -lirc -ldl -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i586-suse-linux/4.0.2/crtend.o /usr/lib/gcc/i586-suse-linux/4.0.2/../../../crtn.o At the moment ld is 113M... growing: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 11700 oracle 18 0 228m 113m 468 D 0.3 46.8 0:12.04 ld linux:~ # free total used free shared buffers cached Mem: 248132 244748 3384 0 1160 14780 -/+ buffers/cache: 228808 19324 Swap: 500432 365584 134848 System is close to unusable. Not sure is it is really a bug of an expected behaviour of gcc 4.0 but the older version do not require so much memory. Thanks Fabrizio