What does major dev =0 means in /proc/pid/maps - linux

an example for /proc/pid/maps
0022a000-00245000 r-xp 00000000 ca:01 11633540 /lib/ld-2.5.so
00245000-00246000 r--p 0001a000 ca:01 11633540 /lib/ld-2.5.so
00246000-00247000 rw-p 0001b000 ca:01 11633540 /lib/ld-2.5.so
00249000-003a3000 r-xp 00000000 ca:01 11633640 /lib/i686/nosegneg/libc-2.5.so
003a3000-003a5000 r--p 0015a000 ca:01 11633640 /lib/i686/nosegneg/libc-2.5.so
003a5000-003a6000 rw-p 0015c000 ca:01 11633640 /lib/i686/nosegneg/libc-2.5.so
003a6000-003a9000 rw-p 003a6000 00:00 0
00ada000-00adb000 r-xp 00ada000 00:00 0 [vdso]
08048000-08049000 r-xp 00000000 00:16 4735574 /home/yimingwa/test/Ctest/link_test/SectionMapping.elf
08049000-0804a000 rw-p 00000000 00:16 4735574 /home/yimingwa/test/Ctest/link_test/SectionMapping.elf
b7fcf000-b7fd0000 rw-p b7fcf000 00:00 0
b7fe1000-b7fe2000 rw-p b7fe1000 00:00 0
bfe82000-bfe98000 rw-p bffe8000 00:00 0 [stack]
the 4th column means “If the region was mapped from a file, this is the major and minor device number (in hex) where the file lives”
In the above, ca:01 I can find through /proc/devices /dev
Question is that what does "00:16" 00 means which major device?

Related

Size of data segment in /proc/pid/maps

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]

*** buffer overflow detected ***: php terminated

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.

Process State replication

I Need to create process state replication between two processes.
I am using a simple bash script that count to infinity.
I am running it on server 1 and server 2 and making the process on server 2 always paused and i need to copy the state (memory) from the first process to the second one (the replica).
I am very familar with procfs and I know that the memory pages contains the state in memory page as follows:
root#ubuntu:/proc/41932# cat maps
7f7254d85000-7f7254f40000 r-xp 00000000 00:27 30 /lib/x86_64-linux-gnu/libc-2.19.so
7f7254f40000-7f725513f000 ---p 001bb000 00:27 30 /lib/x86_64-linux-gnu/libc-2.19.so
7f725513f000-7f7255143000 r--p 001ba000 00:27 30 /lib/x86_64-linux-gnu/libc-2.19.so
7f7255143000-7f7255145000 rw-p 001be000 00:27 30 /lib/x86_64-linux-gnu/libc-2.19.so
7f7255145000-7f725514a000 rw-p 00000000 00:00 0
7f725514a000-7f725516d000 r-xp 00000000 00:27 27 /lib/x86_64-linux-gnu/ld-2.19.so
7f7255364000-7f7255367000 rw-p 00000000 00:00 0
7f725536a000-7f725536c000 rw-p 00000000 00:00 0
7f725536c000-7f725536d000 r--p 00022000 00:27 27 /lib/x86_64-linux-gnu/ld-2.19.so
7f725536d000-7f725536e000 rw-p 00023000 00:27 27 /lib/x86_64-linux-gnu/ld-2.19.so
7f725536e000-7f725536f000 rw-p 00000000 00:00 0
7f725536f000-7f725538b000 r-xp 00000000 00:27 22 /bin/dash
7f725558a000-7f725558c000 r--p 0001b000 00:27 22 /bin/dash
7f725558c000-7f725558d000 rw-p 0001d000 00:27 22 /bin/dash
7f725558d000-7f725558f000 rw-p 00000000 00:00 0
7f7256799000-7f72567ba000 rw-p 00000000 00:00 0 [heap]
7fff06be2000-7fff06c03000 rw-p 00000000 00:00 0 [stack]
7fff06cb8000-7fff06cba000 r-xp 00000000 00:00 0 [vdso]
7fff06cba000-7fff06cbc000 r--p 00000000 00:00 0 [vvar]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
root#ubuntu:/proc/41932# ls map_files/
7f7254d85000-7f7254f40000 7f725513f000-7f7255143000 7f725514a000-7f725516d000 7f725536d000-7f725536e000 7f725558a000-7f725558c000
7f7254f40000-7f725513f000 7f7255143000-7f7255145000 7f725536c000-7f725536d000 7f725536f000-7f725538b000 7f725558c000-7f725558d000
Which files i need to copy knowing that both start from the same script and how to copy this state?

memory map of a shared library in linux

When I look at a process's memory map using
cat /proc/pid/maps
There are entries like this:
40321000-40336000 r-xp 00000000 b3:15 875 /system/lib/libm.so
40336000-40337000 r--p 00014000 b3:15 875 /system/lib/libm.so
40337000-40338000 rw-p 00015000 b3:15 875 /system/lib/libm.so
40338000-40345000 r-xp 00000000 b3:15 789 /system/lib/libcutils.so
40345000-40346000 r--p 0000c000 b3:15 789 /system/lib/libcutils.so
40346000-40347000 rw-p 0000d000 b3:15 789 /system/lib/libcutils.so
40347000-40355000 rw-p 00000000 00:00 0
40355000-403bc000 r-xp 00000000 b3:15 877 /system/lib/libmedia.so
403bc000-403bd000 ---p 00000000 00:00 0
403bd000-403d0000 r--p 00067000 b3:15 877 /system/lib/libmedia.so
403d0000-403d1000 rw-p 0007a000 b3:15 877 /system/lib/libmedia.so
403d1000-403d5000 rw-p 00000000 00:00 0
403d5000-403d8000 rw-p 00000000 00:00 0
I understand the .so represents the shared libraries the process maps. It seems each .so has 3 entries and their permissions are
r-xp
r--p
rw-p
So how do I interpret this? Can I assume the r-xp is the code section of the library, since it has the x (execute) permission? How about the r--p and rw-p, are they the data sections?
What about the empty entries? For example, the last 6 entries about libmedia have three empty entires (00:00 0). What are these?
403bc000-403bd000 ---p 00000000 00:00 0
403bd000-403d0000 r--p 00067000 b3:15 877 /system/lib/libmedia.so
403d0000-403d1000 rw-p 0007a000 b3:15 877 /system/lib/libmedia.so
403d1000-403d5000 rw-p 00000000 00:00 0
403d5000-403d8000 rw-p 00000000 00:00 0
Can I assume the r-xp is the code section of the library, since it has
the x (execute) permission?
Yes, but this is known as text segment(which stores the instruction). You should also note that it does not have write permission as it should not have.
How about the r--p and rw-p, are they the data sections?
Yes,These segments store the static/global variable. However constant global variable would be stored into r--p segment as it should not be modifiable by any program.
What about the empty entries? For example, the last 6 entries about
libmedia have three empty entires (00:00 0). What are these?
These might be the guard segment(kernel inserts these segments to protect the overflow scenario). The "p" indicates that its private.
EDIT
For complete information, you may want to refer the following link:
http://linux.die.net/man/5/proc

netbeans 7.4 linux mint install error

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]

Resources