libstdc++.so.6.0.13: failed to map segment from shared object: Cannot allocate memory

dayalan_cse · 01-21-2015, 11:30 PM

Hello All,

In Linux 32-bit mode, when i run a application, I see the below error.

Please note: this is not specific to any application as it is related to loading sharedobject from .so file to RAM or virtual memory swap in content from disk to RAM.

Error:
----------
libstdc++.so.6: failed to map segment from shared object: Cannot allocate memory

Does anybody have run in to this error? I looked for information in net, I found that we can use /usr/local/bin/softlimit but i dont find this command in my Linux installation.

Does anybody run in to this error and resolved it? please share some information.

a4z · 01-22-2015, 01:04 AM

check this thread, was possible the same problem
http://www.linuxquestions.org/questi...object-801827/

NevemTeve · 01-22-2015, 02:58 AM

Code:

strace <executable>

might show something (not for beginners, though)

dayalan_cse · 01-28-2015, 10:20 PM

Quote:

Originally Posted by NevemTeve

Code:

strace <executable>

might show something (not for beginners, though)

I tried, strace, mmap2 failed with ENOMEM return code.

mmap2(NULL, 955544, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 12, 0) = -1 ENOMEM (Cannot allocate memory)

955544 is this bytes? or Kb? or Mb? I guess it should be bytes which comes around 933 Kb.

Does it mean the system does not have enough virtual memory or its user limit set for individual user id?

I did use, limit to identify what are the resource limits.

cputime unlimited
filesize unlimited
datasize unlimited
stacksize unlimited
coredumpsize unlimited
memoryuse unlimited
vmemoryuse unlimited
descriptors 1024
memorylocked 32 kbytes
maxproc 192801

vmemoryuse is nothing but, virtual memory is 'unlimited', so it is not clear why mmap2 is unable to allocate memory?

Please note, the same application if i run with 64-bit binaries, I dont see this 'mmap2 ENOMEM' error.

a4z · 01-29-2015, 01:06 AM

unlimited on 32 bit is not unlimited, its a lower limit than the 'unlimited' on 64 bit
and the address space for a single process is more limited on 32 bit, (~4 GB) than on 64 bit (~ very much)
this might explain why you run out of memory on 32 bit but not in 64 bit.

you can try to use MAP_SHARED instead of private since private uses much more memory

Quote:

MAP_SHARED Share this mapping. Updates to the mapping are visible to
other processes that map this file, and are carried through
to the underlying file. The file may not actually be
updated until msync(2) or munmap() is called.

MAP_PRIVATE
Create a private copy-on-write mapping. Updates to the map-
ping are not visible to other processes mapping the same
file, and are not carried through to the underlying file.
It is unspecified whether changes made to the file after the
mmap() call are visible in the mapped region.

MAP_DENYWRITE is unused

not also

Quote:

ENOMEM No memory is available, or the process’s maximum number of map-
pings would have been exceeded.

do you map more than one file?

sundialsvcs · 01-29-2015, 07:56 AM

Indeed ... if you map the area "private," this specifies "copy-on-write (COW)" semantics, in which you receive a private copy of each shared page if you touch them. This comes out of your private virtual memory allocation. This combination of options, therefore, seems strange and wasteful to me.