I am trying to understand memory mapping in Linux, and wrote below program for the same.
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#define MEM_SIZE 1*1024*1024*1024 // 1GB
#define PAGE_SIZE 4*1024
#define NO_OF_PAGES (MEM_SIZE)/(PAGE_SIZE)
// Global array of size 1 GB
int mem[MEM_SIZE/sizeof(int)] = {
0,1,2,
};
void *func(void *args)
{
while (1) {
for (int i=0; i<NO_OF_PAGES; i++) {
mem[(i*PAGE_SIZE)/sizeof(int)] = 1; // Update first 4-bytes of each page.
}
// All pages are updated.
fflush(stdout);
printf("."); // Each dot(.) represents update of all pages in global data.
}
return NULL;
}
int main() {
pthread_t t;
pthread_create(&t, NULL, func, NULL);
printf("A thread is continually updating all pages of global 1GB data. (pid : %d)\n", getpid());
pthread_join(t, NULL);
return 0;
}
It executes like this,
[ ] gcc test.c
[ ] ./a.out
A thread is continually updating all pages of global 1GB data. (pid : 4086)
.......................
Here, a thread is continually updating all pages of the global data used in this program.
Hence, this process should consume ~1GB (MEM_SIZE) in memory.
But the process memory looks like below, (I can not see 1GB of data memory being used here).
[ ]# cat /proc/4086/maps
55eac3b7c000-55eac3b7d000 r--p 00000000 08:01 1197055 /root/testing/a.out
55eac3b7d000-55eac3b7e000 r-xp 00001000 08:01 1197055 /root/testing/a.out
55eac3b7e000-55eac3b7f000 r--p 00002000 08:01 1197055 /root/testing/a.out
55eac3b7f000-55eac3b80000 r--p 00002000 08:01 1197055 /root/testing/a.out
55eac3b80000-55eb03b81000 rw-p 00003000 08:01 1197055 /root/testing/a.out
55eb047b5000-55eb047d6000 rw-p 00000000 00:00 0 [heap]
7f19c791b000-7f19c791c000 ---p 00000000 00:00 0
7f19c791c000-7f19c811e000 rw-p 00000000 00:00 0
7f19c811e000-7f19c8140000 r--p 00000000 08:01 1969450 /usr/lib/libc.so.6
7f19c8140000-7f19c829b000 r-xp 00022000 08:01 1969450 /usr/lib/libc.so.6
7f19c829b000-7f19c82f2000 r--p 0017d000 08:01 1969450 /usr/lib/libc.so.6
7f19c82f2000-7f19c82f6000 r--p 001d4000 08:01 1969450 /usr/lib/libc.so.6
7f19c82f6000-7f19c82f8000 rw-p 001d8000 08:01 1969450 /usr/lib/libc.so.6
7f19c82f8000-7f19c8307000 rw-p 00000000 00:00 0
7f19c8311000-7f19c8312000 r--p 00000000 08:01 1969441 /usr/lib/ld-linux-x86-64.so.2
7f19c8312000-7f19c8338000 r-xp 00001000 08:01 1969441 /usr/lib/ld-linux-x86-64.so.2
7f19c8338000-7f19c8342000 r--p 00027000 08:01 1969441 /usr/lib/ld-linux-x86-64.so.2
7f19c8342000-7f19c8344000 r--p 00031000 08:01 1969441 /usr/lib/ld-linux-x86-64.so.2
7f19c8344000-7f19c8346000 rw-p 00033000 08:01 1969441 /usr/lib/ld-linux-x86-64.so.2
7ffe8b517000-7ffe8b538000 rw-p 00000000 00:00 0 [stack]
7ffe8b599000-7ffe8b59d000 r--p 00000000 00:00 0 [vvar]
7ffe8b59d000-7ffe8b59f000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
[ ]#
Though, meminfo reflects the consumption of ~1GB.
Before starting this program:
[ ]# cat /proc/meminfo | grep 'MemFree\|SwapFree'
MemFree: 6740324 kB
SwapFree: 0 kB
and after starting the program:
[ ]# cat /proc/meminfo | grep 'MemFree\|SwapFree'
MemFree: 5699312 kB
SwapFree: 0 kB
In the map, we can see the following zones:
7f19c791b000-7f19c791c000 ---p 00000000 00:00 0 : Red zone to protect the stack of the thread = non RW 4KB long page (stack overflow detection)
7f19c791c000-7f19c811e000 rw-p 00000000 00:00 0 : Stack of the thread (it grows from high to low memory addresses)
55eac3b80000-55eb03b81000 rw-p 00003000 08:01 1197055 : the 1 GB memory space (mem[] table) + 4KB
You could add to your program the display of the mem[] table address:
printf("A thread is continually updating all pages of global 1GB data (mem[]#%p). (pid : %d)\n", mem, getpid());
The size command displays the size of the data segment which is ~1GB:
$ gcc test.c -l pthread
$ size a.out
text data bss dec hex filename
2571 1073742504 16 1073745091 40000cc3 a.out
Execution which shows mem[]'s address at: 0x562c48575020
$ ./a.out
A thread is continually updating all pages of global 1GB data (mem[]#0x562c48575020). (pid : 10029)
.............................................
Display of the map from another terminal where we can see the address of mem[] located in the zone 562c48575000-562c88576000:
$ cat /proc/`pidof a.out`/maps
562c48571000-562c48572000 r--p 00000000 08:05 9044419 /home/xxx/a.out
562c48572000-562c48573000 r-xp 00001000 08:05 9044419 /home/xxx/a.out
562c48573000-562c48574000 r--p 00002000 08:05 9044419 /home/xxx/a.out
562c48574000-562c48575000 r--p 00002000 08:05 9044419 /home/xxx/a.out
562c48575000-562c88576000 rw-p 00003000 08:05 9044419 /home/xxx/a.out
562c89668000-562c89689000 rw-p 00000000 00:00 0 [heap]
7f02946be000-7f02946bf000 ---p 00000000 00:00 0
7f02946bf000-7f0294ebf000 rw-p 00000000 00:00 0
7f0294ebf000-7f0294ee1000 r--p 00000000 08:05 6031519 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f0294ee1000-7f0295059000 r-xp 00022000 08:05 6031519 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f0295059000-7f02950a7000 r--p 0019a000 08:05 6031519 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f02950a7000-7f02950ab000 r--p 001e7000 08:05 6031519 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f02950ab000-7f02950ad000 rw-p 001eb000 08:05 6031519 /usr/lib/x86_64-linux-gnu/libc-2.31.so
7f02950ad000-7f02950b1000 rw-p 00000000 00:00 0
7f02950b7000-7f02950bd000 r--p 00000000 08:05 6031549 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7f02950bd000-7f02950ce000 r-xp 00006000 08:05 6031549 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7f02950ce000-7f02950d4000 r--p 00017000 08:05 6031549 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7f02950d4000-7f02950d5000 r--p 0001c000 08:05 6031549 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7f02950d5000-7f02950d6000 rw-p 0001d000 08:05 6031549 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
7f02950d6000-7f02950da000 rw-p 00000000 00:00 0
7f02950fc000-7f02950ff000 rw-p 00000000 00:00 0
7f02950ff000-7f0295100000 r--p 00000000 08:05 6031511 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f0295100000-7f0295123000 r-xp 00001000 08:05 6031511 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f0295123000-7f029512b000 r--p 00024000 08:05 6031511 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f029512c000-7f029512d000 r--p 0002c000 08:05 6031511 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f029512d000-7f029512e000 rw-p 0002d000 08:05 6031511 /usr/lib/x86_64-linux-gnu/ld-2.31.so
7f029512e000-7f029512f000 rw-p 00000000 00:00 0
7f0295131000-7f0295133000 rw-p 00000000 00:00 0
7ffcb340f000-7ffcb3430000 rw-p 00000000 00:00 0 [stack]
7ffcb35ff000-7ffcb3603000 r--p 00000000 00:00 0 [vvar]
7ffcb3603000-7ffcb3605000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
I am trying to understand the basic of linux process memory layout and i got this program:
#include <stdio.h> // standard io
#include <stdlib.h> // C standard library
#include <pthread.h> // threading
#include <unistd.h> // unix standard library
#include <sys/types.h> // system types for linux
// getchar basically is like "read"
// it prompts the user for input
// in this case, the input is thrown away
// which makes similar to a "pause" continuation primitive
// but a pause that is resolved through user input, which we promptly throw away!
void * thread_func (void * arg) {
printf("Before malloc in thread 1\n");
getchar();
char * addr = (char *) malloc(1000);
printf("After malloc and before free in thread 1\n");
getchar();
free(addr);
printf("After free in thread 1\n");
getchar();
}
int main () {
char * addr;
printf("Welcome to per thread arena example::%d\n", getpid());
printf("Before malloc in the main thread\n");
getchar();
addr = (char *) malloc(1000);
printf("After malloc and before free in main thread\n");
getchar();
free(addr);
printf("After free in main thread\n");
getchar();
// pointer to the thread 1
pthread_t thread_1;
// pthread_* functions return 0 upon succeeding, and other numbers upon failing
int pthread_status;
pthread_status = pthread_create(&thread_1, NULL, thread_func, NULL);
if (pthread_status != 0) {
printf("Thread creation error\n");
return -1;
}
// returned status code from thread_1
void * thread_1_status;
pthread_status = pthread_join(thread_1, &thread_1_status);
if (pthread_status != 0) {
printf("Thread join error\n");
return -1;
}
return 0;
}
When I started the program, the content in /proc/<pid>/maps is:
00400000-00401000 r-xp 00000000 08:01 1323314 /home/oscp/xg/c/memory_layout/a.out
00600000-00601000 r--p 00000000 08:01 1323314 /home/oscp/xg/c/memory_layout/a.out
00601000-00602000 rw-p 00001000 08:01 1323314 /home/oscp/xg/c/memory_layout/a.out
7fcc372d7000-7fcc37491000 r-xp 00000000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37691000-7fcc37695000 r--p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37695000-7fcc37697000 rw-p 001be000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37697000-7fcc3769c000 rw-p 00000000 00:00 0
7fcc3769c000-7fcc376b5000 r-xp 00000000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc376b5000-7fcc378b4000 ---p 00019000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc378b4000-7fcc378b5000 r--p 00018000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc378b5000-7fcc378b6000 rw-p 00019000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc378b6000-7fcc378ba000 rw-p 00000000 00:00 0
7fcc378ba000-7fcc378dd000 r-xp 00000000 08:01 1053733 /lib/x86_64-linux-gnu/ld-2.19.so
7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0
7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0
7fcc37adc000-7fcc37add000 r--p 00022000 08:01 1053733 /lib/x86_64-linux-gnu/ld-2.19.so
7fcc37add000-7fcc37ade000 rw-p 00023000 08:01 1053733 /lib/x86_64-linux-gnu/ld-2.19.so
7fcc37ade000-7fcc37adf000 rw-p 00000000 00:00 0
7ffdc1cff000-7ffdc1d20000 rw-p 00000000 00:00 0 [stack]
7ffdc1dd8000-7ffdc1ddb000 r--p 00000000 00:00 0 [vvar]
7ffdc1ddb000-7ffdc1ddd000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
What are the purposes of these memory regions?
7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
...
7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0
7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0
Then I press enter a few times after running the program. After it prints "Before malloc in thread 1". The memory layout looks like below:
00400000-00401000 r-xp 00000000 08:01 1323314 /home/oscp/xg/c/memory_layout/a.out
00600000-00601000 r--p 00000000 08:01 1323314 /home/oscp/xg/c/memory_layout/a.out
00601000-00602000 rw-p 00001000 08:01 1323314 /home/oscp/xg/c/memory_layout/a.out
00632000-00653000 rw-p 00000000 00:00 0 [heap]
7fcc36ad6000-7fcc36ad7000 ---p 00000000 00:00 0
7fcc36ad7000-7fcc372d7000 rw-p 00000000 00:00 0
7fcc372d7000-7fcc37491000 r-xp 00000000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37691000-7fcc37695000 r--p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37695000-7fcc37697000 rw-p 001be000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37697000-7fcc3769c000 rw-p 00000000 00:00 0
7fcc3769c000-7fcc376b5000 r-xp 00000000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc376b5000-7fcc378b4000 ---p 00019000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc378b4000-7fcc378b5000 r--p 00018000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc378b5000-7fcc378b6000 rw-p 00019000 08:01 1053877 /lib/x86_64-linux-gnu/libpthread-2.19.so
7fcc378b6000-7fcc378ba000 rw-p 00000000 00:00 0
7fcc378ba000-7fcc378dd000 r-xp 00000000 08:01 1053733 /lib/x86_64-linux-gnu/ld-2.19.so
7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0
7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0
7fcc37adc000-7fcc37add000 r--p 00022000 08:01 1053733 /lib/x86_64-linux-gnu/ld-2.19.so
7fcc37add000-7fcc37ade000 rw-p 00023000 08:01 1053733 /lib/x86_64-linux-gnu/ld-2.19.so
7fcc37ade000-7fcc37adf000 rw-p 00000000 00:00 0
7ffdc1cff000-7ffdc1d20000 rw-p 00000000 00:00 0 [stack]
7ffdc1dd8000-7ffdc1ddb000 r--p 00000000 00:00 0 [vvar]
7ffdc1ddb000-7ffdc1ddd000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
What are the purposes of these two regions?
7fcc36ad6000-7fcc36ad7000 ---p 00000000 00:00 0
7fcc36ad7000-7fcc372d7000 rw-p 00000000 00:00 0
After it prints "After malloc and before free in thread 1", it creates another two regions below:
7fcc30000000-7fcc30021000 rw-p 00000000 00:00 0
7fcc30021000-7fcc34000000 ---p 00000000 00:00 0
What are the purposes of these two regions?
Your question covers many completely different things, so the answer will be long.
The first question is the meaning of
7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
in
7fcc372d7000-7fcc37491000 r-xp 00000000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37491000-7fcc37691000 ---p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37691000-7fcc37695000 r--p 001ba000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
7fcc37695000-7fcc37697000 rw-p 001be000 08:01 1053757 /lib/x86_64-linux-gnu/libc-2.19.so
This inaccessible memory region is a gap between adjacent ELF segments of the library (which is supposed to occupy the contiguous chunk of memory). The ---p protection mode forbids using this gap for occasional memory allocation. If you strace(1) the process when it loads the library, you may see something like this:
mmap(NULL, 1848896, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0) = 0x7f9673d8f000
mprotect(0x7f9673db1000, 1671168, PROT_NONE) = 0
mmap(0x7f9673db1000, 1355776, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0x22000) = 0x7f9673db1000
mmap(0x7f9673efc000, 311296, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0x16d000) = 0x7f9673efc000
mmap(0x7f9673f49000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3</usr/lib/libc-2.28.so>, 0x1b9000) = 0x7f9673f49000
The first mmap() maps the first ELF segment into the memory but reserves the space for whole library. This is done to allow the kernel to choose the location for the library on its discretion. To protect any possible gaps between segments mprotect(..., PROT_NONE) is called; then all remaining segments are mapped into the memory using mmap() - this also changes the protection mode of the appropriate memory pages from ---p to whatever mode the segment requires. You may have some fun by taking a look at how it actually works. If you want to verify how this ---p gap is formed during the loading, you may also use readelf(1) with library's binary and do some hexadecimal math with segments' locations and alignments, collating the results with the output of strace.
The second question are the following anonymous mappings:
7fcc36ad6000-7fcc36ad7000 ---p 00000000 00:00 0
7fcc36ad7000-7fcc372d7000 rw-p 00000000 00:00 0
This looks like a thread stack for thread 1. The second mapping is the stack itself (372d7000 - 36ad7000 = 800000 = 8 MiB, which is a default stack size limit in many distros, which, in turn, is a default stack size for pthread), and the first one is a stack guard page. This page with mode ---p protects the stack from overflowing, and triggers the segfault when the overflow happens (because of a write to this write-protected page).
Note: in older Linux kernels, the thread stacks were annotated with [stack:TID] names in maps file, but this feature was removed, so I cannot guarantee that this mapping is really a thread stack (though it looks like). However, you may use strace to find the exact thread's stack location from child_stack argument of clone() syscall and compare with this mapping.
Going on. The third question is
7fcc30000000-7fcc30021000 rw-p 00000000 00:00 0
7fcc30021000-7fcc34000000 ---p 00000000 00:00 0
Well, this is what malloc() in thread 1 did to allocate the memory you have requested. In short, the whole region 7fcc30000000-7fcc34000000 is a heap, from which allocations are done. The rw-p interval 7fcc30000000-7fcc30021000, allocated from this heap, will grow as you will request more and more memory with malloc(). When this heap will deplete, new one will be requested using mmap().
As you probably noticed, I don't have an explanation for the following mappings in your question:
7fcc37abe000-7fcc37ac1000 rw-p 00000000 00:00 0
7fcc37ad8000-7fcc37adc000 rw-p 00000000 00:00 0
I can't recognize those guys quickly and not sure that these are ordinary allocations. Probably this needs separate investigation, as this topic is already too long.
I have dedicated server with WHM when am trying to run any script from the command line am getting the following error but when am running the same script from Root it's run correctly :
Please help :)
*** buffer overflow detected ***: php terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x76e9e6f9e7f7]
/lib64/libc.so.6(+0x1006e0)[0x76e9e6f9c6e0]
/lib64/libc.so.6(+0xffb39)[0x76e9e6f9bb39]
/lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x76e9e6f104a9]
/lib64/libc.so.6(_IO_vfprintf+0x64f)[0x76e9e6ee048f]
/lib64/libc.so.6(__vsprintf_chk+0x9d)[0x76e9e6f9bbdd]
/lib64/libc.so.6(__sprintf_chk+0x7f)[0x76e9e6f9bb1f]
php[0x403328]
php[0x4020e9]
php[0x40171f]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x76e9e6ebad1d]
php[0x4011e9]
======= Memory map: ========
00400000-00404000 r-xp 00000000 09:02 565253 /usr/local/bin/php
00604000-00605000 rw-p 00004000 09:02 565253 /usr/local/bin/php
00605000-01b81000 ---p 00000000 00:00 0
01b81000-01ba2000 rw-p 00000000 00:00 0 [heap]
76e9e6c86000-76e9e6c9c000 r-xp 00000000 09:02 2727991 /lib64/libgcc_s-4.4.7-20120601.so.1
76e9e6c9c000-76e9e6e9b000 ---p 00016000 09:02 2727991 /lib64/libgcc_s-4.4.7-20120601.so.1
76e9e6e9b000-76e9e6e9c000 rw-p 00015000 09:02 2727991 /lib64/libgcc_s-4.4.7-20120601.so.1
76e9e6e9c000-76e9e7026000 r-xp 00000000 09:02 2728045 /lib64/libc-2.12.so
76e9e7026000-76e9e7226000 ---p 0018a000 09:02 2728045 /lib64/libc-2.12.so
76e9e7226000-76e9e722a000 r--p 0018a000 09:02 2728045 /lib64/libc-2.12.so
76e9e722a000-76e9e722c000 rw-p 0018e000 09:02 2728045 /lib64/libc-2.12.so
76e9e722c000-76e9e7230000 rw-p 00000000 00:00 0
76e9e7230000-76e9e724f000 r-xp 00000000 09:02 5392297 /usr/lib64/libyaml-0.so.2.0.4
76e9e724f000-76e9e744e000 ---p 0001f000 09:02 5392297 /usr/lib64/libyaml-0.so.2.0.4
76e9e744e000-76e9e744f000 rw-p 0001e000 09:02 5392297 /usr/lib64/libyaml-0.so.2.0.4
76e9e744f000-76e9e746f000 r-xp 00000000 09:02 2727958 /lib64/ld-2.12.so
76e9e7660000-76e9e7663000 rw-p 00000000 00:00 0
76e9e766b000-76e9e766e000 rw-p 00000000 00:00 0
76e9e766e000-76e9e766f000 r-xp 00000000 00:00 0 [vdso]
76e9e766f000-76e9e7670000 r--p 00020000 09:02 2727958 /lib64/ld-2.12.so
76e9e7670000-76e9e7671000 rw-p 00021000 09:02 2727958 /lib64/ld-2.12.so
76e9e7671000-76e9e7672000 rw-p 00000000 00:00 0
7d3fc456e000-7d3fc458f000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r--p 00000000 0
solved it was an error related to Apache buffering module.
I have python 3.6 installed from source code. And because up arrow key is not working, I installed readline module by 'pip install readline'
But after this, my python console crash.
*** glibc detected *** python: free(): invalid pointer: 0xb7506578 ***
======= Backtrace: =========
/lib/libc.so.6(+0x70e31)[0xce8e31]
python(PyMem_RawFree+0x1b)[0x805faab]
python(PyOS_Readline+0xe0)[0x81c87a0]
python[0x8083924]
python[0x8084007]
python(PyTokenizer_Get+0x17)[0x8084d17]
python[0x80817fc]
python(PyParser_ASTFromFileObject+0x91)[0x8067231]
python(PyRun_InteractiveOneObject+0x111)[0x8068231]
python(PyRun_InteractiveLoopFlags+0x60)[0x80685c0]
python(PyRun_AnyFileExFlags+0x4b)[0x806870b]
python(Py_Main+0xfae)[0x80782ce]
python(main+0x186)[0x805f716]
/lib/libc.so.6(__libc_start_main+0xe6)[0xc8ed26]
python[0x805f4f1]
======= Memory map: ========
0033e000-00366000 r-xp 00000000 fd:00 12964 /lib/libm-2.12.so
00366000-00367000 r--p 00027000 fd:00 12964 /lib/libm-2.12.so
00367000-00368000 rw-p 00028000 fd:00 12964 /lib/libm-2.12.so
00463000-00464000 r-xp 00000000 00:00 0 [vdso]
0048e000-004b0000 r-xp 00000000 fd:00 4544 /lib/libncurses.so.5.7
004b0000-004b1000 rw-p 00021000 fd:00 4544 /lib/libncurses.so.5.7
004e4000-004fb000 r-xp 00000000 fd:00 4246 /lib/libpthread-2.12.so
004fb000-004fc000 r--p 00016000 fd:00 4246 /lib/libpthread-2.12.so
004fc000-004fd000 rw-p 00017000 fd:00 4246 /lib/libpthread-2.12.so
004fd000-004ff000 rw-p 00000000 00:00 0
005f5000-0060b000 r-xp 00000000 fd:00 4548 /lib/libtinfo.so.5.7
0060b000-0060e000 rw-p 00015000 fd:00 4548 /lib/libtinfo.so.5.7
0061b000-00622000 r-xp 00000000 fd:00 12976 /lib/librt-2.12.so
00622000-00623000 r--p 00006000 fd:00 12976 /lib/librt-2.12.so
00623000-00624000 rw-p 00007000 fd:00 12976 /lib/librt-2.12.so
00680000-00682000 r-xp 00000000 fd:00 9932 /lib/libutil-2.12.so
00682000-00683000 r--p 00001000 fd:00 9932 /lib/libutil-2.12.so
00683000-00684000 rw-p 00002000 fd:00 9932 /lib/libutil-2.12.so
00ace000-00afc000 r-xp 00000000 fd:00 387421 /home/i2b2demo/PMI-Project/PMI_id_map_script/pmi/lib/python3.6/site-packages/readline.cpython-36m-i386-linux-gnu.so
00afc000-00b01000 rw-p 0002e000 fd:00 387421 /home/i2b2demo/PMI-Project/PMI_id_map_script/pmi/lib/python3.6/site-packages/readline.cpython-36m-i386-linux-gnu.so
00b01000-00b02000 rw-p 00000000 00:00 0
00c78000-00e09000 r-xp 00000000 fd:00 4203 /lib/libc-2.12.so
00e09000-00e0b000 r--p 00191000 fd:00 4203 /lib/libc-2.12.so
00e0b000-00e0c000 rw-p 00193000 fd:00 4203 /lib/libc-2.12.so
00e0c000-00e0f000 rw-p 00000000 00:00 0
00e63000-00e81000 r-xp 00000000 fd:00 3473 /lib/ld-2.12.so
00e81000-00e82000 r--p 0001d000 fd:00 3473 /lib/ld-2.12.so
00e82000-00e83000 rw-p 0001e000 fd:00 3473 /lib/ld-2.12.so
00ea4000-00ea7000 r-xp 00000000 fd:00 12962 /lib/libdl-2.12.so
00ea7000-00ea8000 r--p 00002000 fd:00 12962 /lib/libdl-2.12.so
00ea8000-00ea9000 rw-p 00003000 fd:00 12962 /lib/libdl-2.12.so
00fc9000-00fe6000 r-xp 00000000 fd:00 15323 /lib/libgcc_s-4.4.7-20120601.so.1
00fe6000-00fe7000 rw-p 0001d000 fd:00 15323 /lib/libgcc_s-4.4.7-20120601.so.1
08048000-08222000 r-xp 00000000 fd:00 394807 /home/i2b2demo/PMI-Project/PMI_id_map_script/pmi/bin/python3.6
08222000-0826d000 rw-p 001d9000 fd:00 394807 /home/i2b2demo/PMI-Project/PMI_id_map_script/pmi/bin/python3.6
0826d000-0828e000 rw-p 00000000 00:00 0
08c10000-08c87000 rw-p 00000000 00:00 0 [heap]
b747f000-b7581000 rw-p 00000000 00:00 0
b7581000-b7781000 r--p 00000000 fd:00 4192 /usr/lib/locale/locale-archive
b7781000-b7783000 rw-p 00000000 00:00 0
b778a000-b7791000 r--s 00000000 fd:00 5148 /usr/lib/gconv/gconv-modules.cache
b7791000-b7792000 rw-p 00000000 00:00 0
bfb0d000-bfb2b000 rw-p 00000000 00:00 0 [stack]
[1] 32069 abort python
Install gnureadline instead of readline
pip uninstall readline
pip install gnureadline
I am having this problem, as well. When I ran "make" in preparation to install python 3.6.1, I saw this output toward the end:
Python build finished successfully!
The necessary bits to build these optional modules were not found:
_bz2 _dbm _gdbm
_lzma _sqlite3 _tkinter
readline
I'm guessing that without the readline binaries present, trying to use the readline Python library will not work. The thing is, I know I've installed the readline binaries previously. From what I can gather, this is an issue with the python installation being able to find them.
UPDATE:
I followed the advice here:
https://gist.github.com/Nesffer/5fb3d6d4cd3e0cb65624
Essentially, just run this command:
sudo apt-get install libbz2-dev libncurses5-dev libgdbm-dev liblzma-dev sqlite3 libsqlite3-dev openssl libssl-dev tcl8.6-dev tk8.6-dev libreadline-dev zlib1g-dev
And then cleaned and reinstalled python 3.6.1. Ensure no traces of python3.6 on your system This fixes the problem for me. I'm sure I had readline installed before, so I'm not entirely sure what the mechanics of this problem are.
I try install netbeans 7.4 for html5 and php develop version on Linux Mint 15 Olivia.But installer throw error wthi next message:
* Error in
`/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200': double free or
corruption (out): 0x089f5720 *
======= Backtrace: ========= /lib/i386-linux-gnu/libc.so.6(+0x767e2)[0xb765d7e2]
/lib/i386-linux-gnu/libc.so.6(+0x77530)[0xb765e530]
/lib/i386-linux-gnu/libz.so.1(+0xd8fb)[0xb77a88fb]
/lib/i386-linux-gnu/libz.so.1(deflateEnd+0x3c)[0xb77a01dc]
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200[0x8057911]
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200[0x8057ad6]
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200[0x804eee0]
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200[0x8058adc]
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200[0x8048f87]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0xb7600935]
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200[0x8048fad]
======= Memory map: ======== 08048000-0805d000 r-xp 00000000 08:08 526424 /usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200
0805d000-0805e000 r--p 00015000 08:08 526424
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200 0805e000-0805f000
rw-p 00016000 08:08 526424
/usr/lib/jvm/java-7-openjdk-i386/jre/bin/unpack200 0805f000-08060000
rw-p 00000000 00:00 0 089ac000-08a16000 rw-p 00000000 00:00 0
[heap] b75ac000-b75c7000 r-xp 00000000 08:01 393963
/lib/i386-linux-gnu/libgcc_s.so.1 b75c7000-b75c8000 r--p 0001a000
08:01 393963 /lib/i386-linux-gnu/libgcc_s.so.1 b75c8000-b75c9000
rw-p 0001b000 08:01 393963 /lib/i386-linux-gnu/libgcc_s.so.1
b75e5000-b75e7000 rw-p 00000000 00:00 0 b75e7000-b7795000 r-xp
00000000 08:01 397441 /lib/i386-linux-gnu/libc-2.17.so
b7795000-b7797000 r--p 001ae000 08:01 397441
/lib/i386-linux-gnu/libc-2.17.so b7797000-b7798000 rw-p 001b0000 08:01
397441 /lib/i386-linux-gnu/libc-2.17.so b7798000-b779b000 rw-p
00000000 00:00 0 b779b000-b77b2000 r-xp 00000000 08:01 394091
/lib/i386-linux-gnu/libz.so.1.2.7 b77b2000-b77b3000 r--p 00016000
08:01 394091 /lib/i386-linux-gnu/libz.so.1.2.7 b77b3000-b77b4000
rw-p 00017000 08:01 394091 /lib/i386-linux-gnu/libz.so.1.2.7
b77cd000-b77d2000 rw-p 00000000 00:00 0 b77d2000-b77d3000 r-xp
00000000 00:00 0 [vdso] b77d3000-b77f3000 r-xp 00000000 08:01
397442 /lib/i386-linux-gnu/ld-2.17.so b77f3000-b77f4000 r--p
0001f000 08:01 397442 /lib/i386-linux-gnu/ld-2.17.so
b77f4000-b77f5000 rw-p 00020000 08:01 397442
/lib/i386-linux-gnu/ld-2.17.so bfa28000-bfa49000 rw-p 00000000 00:00 0
[stack]