Mailing List Archive

/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
Re: /bin/ld: failed to set dynamic section sizes: Memory exhausted [ In reply to ]
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
>
>
>
Re: /bin/ld: failed to set dynamic section sizes: Memory exhausted [ In reply to ]
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.
Re: /bin/ld: failed to set dynamic section sizes: Memory exhausted [ In reply to ]
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.
>
>
>