Maximum virtual memory allocation for a thread in RHEL6 - c

Question

As RHEL6 introduced a new arena allocator design because of the same number of arena’s are increased for a single thread which is resulting into more virtual memory usage.
RHEL6 is allocating separate chunks of memory for each thread. Number of Arena per thread are calculated as below as per my understanding on 32/64 bit system:
On 32 Bit system :
Number of Arena = 2 * Number of cores .
On 64 Bit system :
Number of Arena = 8 * Number of cores .
Please validate if my understanding have some gap.
My machine has 4 cores and 64 bit system,
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 69
Stepping: 1
CPU MHz: 759.000
BogoMIPS: 4589.41
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 3072K
NUMA node0 CPU(s): 0-3
$ uname -a
Linux admin 3.13.0-71-generic #114-Ubuntu SMP Tue Dec 1 02:34:22 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
So it has 4*8=32 Arena's per thread. Each arena has a maximum size of 64MB; pet thread virtual memory can be reached to 32*64=2GB(per thread).
Please let me know if my understanding is correct.
I have created a sample program. It is allocated 1.5 GB of heap memory.
#include <pthread.h>
#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <malloc.h>
#include <unistd.h>
static void *thread(void *arg)
{
int i=0;
char *x[1024];
unsigned int pid;
char str[15];
char cmd[30]="cat /proc/";
pid = getpid();
sprintf(str, "%d", pid);
strcat(cmd,str);
strcat(cmd,"/status");
system(cmd);
for(i=0;i<1536;i++)
{
x[i] = malloc(1*1024*1024);
printf("Memory Allocated %d:\n ",i);
system(cmd);
}
for(i=0;i<1536;i++)
{
*x[i] = 5;
free(x[i]);
}
return NULL;
}
int main(void)
{
unsigned i;
pthread_t t;
pthread_create(&t, NULL, thread, NULL);
pthread_join(t, NULL);
return 0;
}
thread t is heap memory allocation is lesser than 2GB. but it generates the coredump after allocating 1GB approx. For more detail please refer the below detail:
Name: arena
State: S (sleeping)
Tgid: 12511
Ngid: 0
Pid: 12511
PPid: 4417
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groups: 4 24 27 30 46 108 124 129 1000
VmPeak: 1133924 kB
VmSize: 1133924 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 4568 kB
VmRSS: 4568 kB
VmData: 1127636 kB
VmStk: 136 kB
VmExe: 4 kB
VmLib: 2012 kB
VmPTE: 2092 kB
VmSwap: 0 kB
Threads: 2
SigQ: 0/46560
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000006
SigCgt: 0000000180000000
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
Seccomp: 0
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 1027
nonvoluntary_ctxt_switches: 4
Why the coredump generated? is my above understanding is incorrect to calculate the thread maximum virtual memory?
Also what are the consequences happened if virtual memory maximum limit reached
Please note I have set ulimit to unlimited
$ ulimit
unlimited

Answer 1

Why the coredump generated?
You have
char *x[1024];
…
for(i=0;i<1536;i++)
{
x[i] = malloc(1*1024*1024);
- a plain case of array overflow.

Answer 2

Memory allocation generally isn't specific to any distribution. Typically, the allocator is the glibc implementation. However, the amount of memory a thread can allocate should be a function of the kernel, not the allocator. Some of the reasons you wouldn't be able to allocate memory might include exhausting physical memory, exhausting swap memory, ulimit, cgroups, etc...
If you still suspect the allocator though, you can try using mmap to directly map the memory into the process.