Re: [Valgrind-users] Swap Space Problem

[John R. <jr...@Bi...>]

Mitchell Kang wrote:
> The setting is Redhat AS 2.1 server with 4 CPUs, 8 GB of RAM and 8 GB of swap.
[snip]
> When I ran the following command after changing the stack_size to 28 because of the same problem
> 
>  #define VG_PTHREAD_STACK_SIZE (1 << 28)
> 
> valgrind --alignment=8 --skin=addrcheck --error-limit=no --leak-check=yes --num-callers=1 binary
> 
[snip]
> ==23496== Warning: set address range perms: large range 268435424, a 1
>  
> VG_(get_memory_from_mmap): request for 8192 bytes failed.
> VG_(get_memory_from_mmap): 2119042790 bytes already allocated.
[snip]
> I believe I have enough swap space.  Is there anything I can try?


It's possible that your address space is fragmented by having TASK_UNMAPPED_BASE
at 0x40000000, and a pre-linked glibc at 0x42000000.  TASK_UNNMAPPED_BASE is the
default address where dynamic loading takes place, as well as the beginning
address to search for space to satisfy any mmap(0, ...) system call that does
not specify MAP_FIXED.  While the process is running, do "cat /proc/<pid>/maps"
to see the layout of its address space.

Search google groups for Message-ID: <bc5igc$fu9$1...@rz...>
(Re: 64-bit memory management) by Ulrich Weigand, 6/10/2003 02:27PM to see a
claim that RHAS has a patch that lets you set the map_base by writing an ASCII
hex numeral to /proc/<pid>/map_base.  The referenced patch is
http://kernelnewbies.org/kernels/rh21as/SOURCES/linux-2.4.9-task-map-base.patch
With some investigating on your part ("ldd ./my_app"), then you can pick a good
place for map_base.

Your next problem may be a pre-linked libc.so.6 at 0x42000000.
The runtime loader asks the kernel for mmap(0x42000000, ...) and most likely
the kernel grants that address, which means fragmentation.  Try to find a non-
prelinked glibc of the appropriate version.  If you are willing to try some
tricks, then see  http://www.bitwagon.com/tub.html  for experimental code which
lets you move even a pre-linked glibc.  This doesn't give you any more total
space; however it may reduce the fragmentation by enough to squeak by.  Else
you will have to use Insure++ or Purify on a 64-bit RISC machine, or help get
valgrind on an AMD x86_64.

Regards,