Re: [Valgrind-users] Swap Space Problem

[Julian S. <js...@ac...>]

On Monday 16 June 2003 21:37, Mitchell Kang wrote:
> The setting is Redhat AS 2.1 server with 4 CPUs, 8 GB of RAM and 8 GB of
> swap.
>
> The application is compiled with gcc 2.96-112.
>
> 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)

Are you sure this is a good idea?  It means each thread stack occupies
256MB, and no sane piece of code is going to require that much.  It would
be far too fragile and unportable.  This is probably why you've run
out of 2GB of address space, by the look of it.

J


> valgrind --alignment=8 --skin=addrcheck --error-limit=no --leak-check=yes
> --num-callers=1 binary
>
> ==23496== Warning: set address range perms: large range 268435424, a 1
> ==23496== valgrind's libpthread.so: KLUDGED call to: pthread_cond_destroy
> ==23496== valgrind's libpthread.so: IGNORED call to:
> pthread_attr_setinheritsched ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==23496== Warning: set address range perms:
> large range 268435424, a 1 ==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.
>
> This may mean that you have run out of swap space,
> since running programs on valgrind increases their memory
> usage at least 3 times.  You might want to use 'top'
> to determine whether you really have run out of swap.
> If so, you may be able to work around it by adding a
> temporary swap file -- this is easier than finding a
> new swap partition.  Go ask your sysadmin(s) [politely!]
>
> VG_(get_memory_from_mmap): out of memory!  Fatal!  Bye!
>
> I believe I have enough swap space.  Is there anything I can try?
>
> Thanks for your help.
>
> Mitch
>
> --
> NOTICE: If received in error, please destroy and notify sender.  Sender
> does not waive confidentiality or privilege, and use is prohibited.