FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Hardened

 
 
LinkBack Thread Tools
 
Old 09-07-2012, 12:16 PM
"Tóth Attila"
 
Default /bin/ld: failed to set dynamic section sizes: Memory exhausted

I have a 32-bit (Athlon MP) machine running Hardened Gentoo. The system
has 4Gb of RAM, but it only sees around 3.6Gb due to hardware reasons.

Recently I couldn't upgrade either thunderbird or seamonkey, because a the
most important linking dies with this error message:
/usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../i686-pc-linux-gnu/bin/ld:
failed to set dynamic section sizes: Memory exhausted

The linker process consumes nearly one third of the system memory. The top
virtual memory consumption is around 35.9% for a moment before
termination, but I couldn't capture it. Here is how it stays for a minute
before the process dies (taken from top):
10263 root 20 0 1176m 1.1g 2668 R 100 31.9 1:11.82 ld

In the mean time, top also shows, that we have still a lot of memory to use:
Mem: 3606828k total, 3164612k used, 442216k free, 110976k buffers
Swap: 4530136k total, 0k used, 4530136k free, 1109312k cached
No swapping.

I tried it right after a fresh reboot.

ulimit -a:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 28178
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 28178
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

Omitting "-pipe" from CFLAGS didn't help. What else can I try to compile
these binaries? Are there any PaX or Grsec kernel options with a potential
influence?
Should I accept, that I cannot compile thunderbird or seamonkey on a 32bit
architecture having 4G of RAM these days?

If anybody have an idea, please don't hesitate.

Regards:
Dwokfur
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057
 
Old 09-07-2012, 12:22 PM
"Tóth Attila"
 
Default /bin/ld: failed to set dynamic section sizes: Memory exhausted

I also started to be afraid. I have only 8Gb in my 64bit laptop and I'm
currently replacing the server (not because of the symptoms) to core-i7
with 16Gb of RAM. How long will it be enough if 3.6Gb on a 32bit already
too small?
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Szeptember 7.(P) 14:16 idÅ‘pontban "Tóth Attila" ezt Ã*rta:
> I have a 32-bit (Athlon MP) machine running Hardened Gentoo. The system
> has 4Gb of RAM, but it only sees around 3.6Gb due to hardware reasons.
>
> Recently I couldn't upgrade either thunderbird or seamonkey, because a the
> most important linking dies with this error message:
> /usr/lib/gcc/i686-pc-linux-gnu/4.6.3/../../../../i686-pc-linux-gnu/bin/ld:
> failed to set dynamic section sizes: Memory exhausted
>
> The linker process consumes nearly one third of the system memory. The top
> virtual memory consumption is around 35.9% for a moment before
> termination, but I couldn't capture it. Here is how it stays for a minute
> before the process dies (taken from top):
> 10263 root 20 0 1176m 1.1g 2668 R 100 31.9 1:11.82 ld
>
> In the mean time, top also shows, that we have still a lot of memory to
> use:
> Mem: 3606828k total, 3164612k used, 442216k free, 110976k buffers
> Swap: 4530136k total, 0k used, 4530136k free, 1109312k cached
> No swapping.
>
> I tried it right after a fresh reboot.
>
> ulimit -a:
> core file size (blocks, -c) 0
> data seg size (kbytes, -d) unlimited
> scheduling priority (-e) 0
> file size (blocks, -f) unlimited
> pending signals (-i) 28178
> max locked memory (kbytes, -l) 64
> max memory size (kbytes, -m) unlimited
> open files (-n) 1024
> pipe size (512 bytes, -p) 8
> POSIX message queues (bytes, -q) 819200
> real-time priority (-r) 0
> stack size (kbytes, -s) 8192
> cpu time (seconds, -t) unlimited
> max user processes (-u) 28178
> virtual memory (kbytes, -v) unlimited
> file locks (-x) unlimited
>
> Omitting "-pipe" from CFLAGS didn't help. What else can I try to compile
> these binaries? Are there any PaX or Grsec kernel options with a potential
> influence?
> Should I accept, that I cannot compile thunderbird or seamonkey on a 32bit
> architecture having 4G of RAM these days?
>
> If anybody have an idea, please don't hesitate.
>
> Regards:
> Dwokfur
> --
> dr Tóth Attila, Radiológus, 06-20-825-8057
> Attila Toth MD, Radiologist, +36-20-825-8057
>
>
>
 
Old 09-07-2012, 12:44 PM
"PaX Team"
 
Default /bin/ld: failed to set dynamic section sizes: Memory exhausted

On 7 Sep 2012 at 14:16, "Tóth Attila" wrote:

> Omitting "-pipe" from CFLAGS didn't help. What else can I try to compile
> these binaries? Are there any PaX or Grsec kernel options with a potential
> influence?

i guess you're using SEGMEXEC which limits the process virtual address space
size to 1.5G and that is apparently not enough to link these binaries anymore.
you can disable SEGMEXEC on the gcc/ld binaries and perhaps USE=-debug if you
have it enabled as it can consume more memory at link time for larger binaries.
 
Old 09-07-2012, 07:47 PM
"Tóth Attila"
 
Default /bin/ld: failed to set dynamic section sizes: Memory exhausted

Disabling SEGMEXEC on ld binary solved the problem. Excelent! It can be
handy for those who still use 32bit in production. It's scary, that
linking needs so much memory. The top memory usage was just above 1.5G
(approx 1.548G). Probably both software has just got exceeded 1.5G.
Without debug.

Thx:
Dw.
--
dr Tóth Attila, Radiológus, 06-20-825-8057
Attila Toth MD, Radiologist, +36-20-825-8057

2012.Szeptember 7.(P) 14:44 idÅ‘pontban PaX Team ezt Ã*rta:
> On 7 Sep 2012 at 14:16, "Tóth Attila" wrote:
>
>> Omitting "-pipe" from CFLAGS didn't help. What else can I try to compile
>> these binaries? Are there any PaX or Grsec kernel options with a
>> potential
>> influence?
>
> i guess you're using SEGMEXEC which limits the process virtual address
> space
> size to 1.5G and that is apparently not enough to link these binaries
> anymore.
> you can disable SEGMEXEC on the gcc/ld binaries and perhaps USE=-debug if
> you
> have it enabled as it can consume more memory at link time for larger
> binaries.
>
>
>
 

Thread Tools




All times are GMT. The time now is 08:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org