Can anybody tell me what is a proc map? How it is useful and how to check it?
Thanks in advance.
Here is one of the proc maps, can someone explain what does it signify?
enter code here
-bash-3.2# cat /proc/2064/maps
00008000-00009000 r-xp 00000000 00:0e 33036189 /tmp/efence/dev.out
00010000-00011000 rw-p 00000000 00:0e 33036189 /tmp/efence/dev.out
00011000-00032000 rw-p 00011000 00:00 0 [heap]
40000000-4001d000 r-xp 00000000 00:0e 32247424 /devel/lib/ld-2.9.so
4001d000-40020000 rw-p 4001d000 00:00 0
40024000-40025000 r--p 0001c000 00:0e 32247424 /devel/lib/ld-2.9.so
40025000-40026000 rw-p 0001d000 00:0e 32247424 /devel/lib/ld-2.9.so
40030000-40157000 r-xp 00000000 00:0e 32247431 /devel/lib/libc-2.9.so
40157000-4015f000 ---p 00127000 00:0e 32247431 /devel/lib/libc-2.9.so
4015f000-40161000 r--p 00127000 00:0e 32247431 /devel/lib/libc-2.9.so
40161000-40162000 rw-p 00129000 00:0e 32247431 /devel/lib/libc-2.9.so
40162000-40165000 rw-p 40162000 00:00 0
beb58000-beb6d000 rw-p befeb000 00:00 0 [stack]
The file /proc/[pid]/maps is a way to see the memory regions mapped by a process. Read about /proc for more info on other useful stuff you can find there.
Related
I have a program, where I am injecting a fault and I am expecting this to cause a segmentation fault. The problem I am facing is that for a fault such as:
char *str = malloc(sizeof(char)*10);
free(str+1);
I get the following printed in the shell:
*** Error in `./tests': free(): invalid pointer: 0x0000000002442574 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x80996)[0x2abd5ff5b996]
./tests[0x401558]
./tests[0x401735]
./tests[0x402211]
./tests[0x402c1b]
./tests[0x4013fd]
./tests[0x4014a2]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2abd5fefcde5]
./tests[0x4011c9]
======= Memory map: ========
00400000-00407000 r-xp 00000000 08:05 13109176 /home/jay/Desktop/Mutate/Mutate/CMeanQueue-master/tests
00606000-00607000 r--p 00006000 08:05 13109176 /home/jay/Desktop/Mutate/Mutate/CMeanQueue-master/tests
00607000-00608000 rw-p 00007000 08:05 13109176 /home/jay/Desktop/Mutate/Mutate/CMeanQueue-master/tests
00608000-0060a000 rw-p 00000000 00:00 0
02440000-02461000 rw-p 00000000 00:00 0 [heap]
2abd5fcb7000-2abd5fcd8000 r-xp 00000000 08:05 11274438 /lib64/ld-2.17.so
2abd5fcd8000-2abd5fcdb000 rw-p 00000000 00:00 0
2abd5fcef000-2abd5fcf2000 rw-p 00000000 00:00 0
2abd5fed8000-2abd5fed9000 r--p 00021000 08:05 11274438 /lib64/ld-2.17.so
2abd5fed9000-2abd5fedb000 rw-p 00022000 08:05 11274438 /lib64/ld-2.17.so
2abd5fedb000-2abd60098000 r-xp 00000000 08:05 6164261 /lib/x86_64-linux-gnu/libc-2.17.so
2abd60098000-2abd60298000 ---p 001bd000 08:05 6164261 /lib/x86_64-linux-gnu/libc-2.17.so
2abd60298000-2abd6029c000 r--p 001bd000 08:05 6164261 /lib/x86_64-linux-gnu/libc-2.17.so
2abd6029c000-2abd6029e000 rw-p 001c1000 08:05 6164261 /lib/x86_64-linux-gnu/libc-2.17.so
2abd6029e000-2abd602a3000 rw-p 00000000 00:00 0
2abd602a3000-2abd602b8000 r-xp 00000000 08:05 6160389 /lib/x86_64-linux-gnu/libgcc_s.so.1
2abd602b8000-2abd604b7000 ---p 00015000 08:05 6160389 /lib/x86_64-linux-gnu/libgcc_s.so.1
2abd604b7000-2abd604b8000 r--p 00014000 08:05 6160389 /lib/x86_64-linux-gnu/libgcc_s.so.1
2abd604b8000-2abd604b9000 rw-p 00015000 08:05 6160389 /lib/x86_64-linux-gnu/libgcc_s.so.1
7fffee8c6000-7fffee8e7000 rw-p 00000000 00:00 0 [stack]
7fffee993000-7fffee995000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Now, what I am looking to do is hide this from the display, since I am making a fault injection tool, I am aware of this happening and do not want such an output to ruin the GUI for the user. I have tried to redirect the stderror to file 2) change unlimit to 0 and nothing works.
NOTE:: I am injecting this problem into a code myself, hence please do not suggest to fix the error. My aim is to hide this from printing on the shell.
THanks
Solved for the above example using:
#export MALLOC_CHECK_=0
http://kb.parallels.com/en/4611
Try changing your kernel log level to limit what it prints.
something like:
bash$ echo "0 0 0 0" > /proc/sys/kernel/printk
Great write up here: Change default console loglevel during boot up
This question already has answers here:
When / How does Linux load shared libraries into address space?
(5 answers)
Closed 9 years ago.
On linux platform,
Could anyone tell me where is the dynamic library in the memory?
I learned that the dynamic library are mmap to the process according to the GOT
of this process,
is that true?
Thank you!
You can see where things got mapped in a Linux process by looking in /proc/pid/maps -- all you need to know is the process id. For example:
$ cat /proc/self/maps
00400000-0040b000 r-xp 00000000 08:01 71827604 /bin/cat
0060a000-0060b000 r--p 0000a000 08:01 71827604 /bin/cat
0060b000-0060c000 rw-p 0000b000 08:01 71827604 /bin/cat
00690000-006b1000 rw-p 00000000 00:00 0 [heap]
7f07fbaf7000-7f07fbdc0000 r--p 00000000 08:01 18094104 /usr/lib/locale/locale-archive
7f07fbdc0000-7f07fbf75000 r-xp 00000000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fbf75000-7f07fc175000 ---p 001b5000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fc175000-7f07fc179000 r--p 001b5000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fc179000-7f07fc17b000 rw-p 001b9000 08:01 14552996 /lib/x86_64-linux-gnu/libc-2.15.so
7f07fc17b000-7f07fc180000 rw-p 00000000 00:00 0
7f07fc180000-7f07fc1a2000 r-xp 00000000 08:01 14553008 /lib/x86_64-linux-gnu/ld-2.15.so
7f07fc37e000-7f07fc381000 rw-p 00000000 00:00 0
7f07fc3a0000-7f07fc3a2000 rw-p 00000000 00:00 0
7f07fc3a2000-7f07fc3a3000 r--p 00022000 08:01 14553008 /lib/x86_64-linux-gnu/ld-2.15.so
7f07fc3a3000-7f07fc3a5000 rw-p 00023000 08:01 14553008 /lib/x86_64-linux-gnu/ld-2.15.so
7fff90e28000-7fff90e49000 rw-p 00000000 00:00 0 [stack]
7fff90f1f000-7fff90f20000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
shows everything that got mapped in to run the cat program.
I just want to know where is (if present!) the Heap of my bash process (pid = 16457) in the result of cat /proc/16457/maps
0078a000-007a0000 r-xp 00000000 08:02 1319336 /lib/ld-2.3.4.so
007a0000-007a1000 r--p 00015000 08:02 1319336 /lib/ld-2.3.4.so
007a1000-007a2000 rw-p 00016000 08:02 1319336 /lib/ld-2.3.4.so
007a9000-008cf000 r-xp 00000000 08:02 1384495 /lib/tls/libc-2.3.4.so
008cf000-008d1000 r--p 00125000 08:02 1384495 /lib/tls/libc-2.3.4.so
008d1000-008d3000 rw-p 00127000 08:02 1384495 /lib/tls/libc-2.3.4.so
008d3000-008d5000 rw-p 008d3000 00:00 0
008fc000-008fe000 r-xp 00000000 08:02 1319337 /lib/libdl-2.3.4.so
008fe000-008ff000 r--p 00001000 08:02 1319337 /lib/libdl-2.3.4.so
008ff000-00900000 rw-p 00002000 08:02 1319337 /lib/libdl-2.3.4.so
00b27000-00b2a000 r-xp 00000000 08:02 278109 /lib/libtermcap.so.2.0.8
00b2a000-00b2b000 rw-p 00002000 08:02 278109 /lib/libtermcap.so.2.0.8
08047000-080d8000 r-xp 00000000 08:02 902412 /bin/bash
080d8000-080de000 rw-p 00090000 08:02 902412 /bin/bash
080de000-080e3000 rw-p 080de000 00:00 0
09ceb000-09d25000 rw-p 09ceb000 00:00 0
b7d99000-b7d9b000 rw-p b7d99000 00:00 0
b7d9b000-b7da1000 r--s 00000000 08:02 130808 /usr/lib/gconv/gconv-modules.cache
b7da1000-b7dd6000 r--s 00000000 08:02 869910 /var/db/nscd/passwd
b7dd6000-b7fd6000 r--p 00000000 08:02 101088 /usr/lib/locale/locale-archive
b7fd6000-b7fd8000 rw-p b7fd6000 00:00 0
bff07000-c0000000 rw-p bff07000 00:00 0
ffffe000-fffff000 r-xp 00000000 00:00 0
"The" heap most people refer to is this line:
080de000-080e3000 rw-p 080de000 00:00 0
i.e. it's the region of memory created and expandable by the brk syscall, immediately following the main program's .data and .bss segments.
One might also consider the following as part of the "heap":
09ceb000-09d25000 rw-p 09ceb000 00:00 0
It seems to be an anonymous mapping created by mmap to service a large malloc request. Most malloc implementations use mmap for large requests so they can munmap it on free and return the whole block of memory to the OS. It also makes calloc much faster since you're guaranteed to get per-zeroed pages this way.
The heap is clearly marked as [heap] in current Linux versions. Your listing doesn't show it. Are you sure you didn't accidentally cut it out when copying it to your question?
On my shell:
~% grep '\[heap' /proc/$$/maps
00bca000-00d2e000 rw-p 00000000 00:00 0 [heap]
The heap usually appears to be marked with [heap] when a malloc call is called; however, you'll notice that if you keep growing the heap with multiple lines of malloc() code that range will not grow; however, new blank line entries will be created.
I have a program that has to use mmf to map a ppm image to memory and then, each child, will have to invert row by row the mmf. It says :"the MMF version will first have to create a copy of the image (and rename it to the destiny filename) and then execute the inversion on that copy." The semaphores are in the correct order too and according to the assignment too.
From this, I've coded and it gives me the correct output but this happens :S. I don't understand why but it's clearly not right:
(...)
Inverting row...
Done ||
Inverting row...
Done ||
Cleaning up...
Closing file pointers.
*** glibc detected *** ./MMF_inverter: double free or corruption (!prev): 0x093a0170 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(+0x6b591)[0x28e591]
/lib/tls/i686/cmov/libc.so.6(+0x6cde8)[0x28fde8]
/lib/tls/i686/cmov/libc.so.6(cfree+0x6d)[0x292ecd]
/lib/tls/i686/cmov/libc.so.6(fclose+0x14a)[0x27eaaa]
./MMF_inverter[0x80497d5]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0x239bd6]
./MMF_inverter[0x8048d01]
======= Memory map: ========
00110000-00125000 r-xp 00000000 08:05 1569987 /lib/tls/i686/cmov/libpthread-2.11.1.so
00125000-00126000 r--p 00014000 08:05 1569987 /lib/tls/i686/cmov/libpthread-2.11.1.so
00126000-00127000 rw-p 00015000 08:05 1569987 /lib/tls/i686/cmov/libpthread-2.11.1.so
00127000-00129000 rw-p 00000000 00:00 0
00129000-00146000 r-xp 00000000 08:05 1439060 /lib/libgcc_s.so.1
00146000-00147000 r--p 0001c000 08:05 1439060 /lib/libgcc_s.so.1
00147000-00148000 rw-p 0001d000 08:05 1439060 /lib/libgcc_s.so.1
00223000-00376000 r-xp 00000000 08:05 1569962 /lib/tls/i686/cmov/libc-2.11.1.so
00376000-00377000 ---p 00153000 08:05 1569962 /lib/tls/i686/cmov/libc-2.11.1.so
00377000-00379000 r--p 00153000 08:05 1569962 /lib/tls/i686/cmov/libc-2.11.1.so
00379000-0037a000 rw-p 00155000 08:05 1569962 /lib/tls/i686/cmov/libc-2.11.1.so
0037a000-0037d000 rw-p 00000000 00:00 0
00459000-0045a000 r-xp 00000000 00:00 0 [vdso]
00471000-0048c000 r-xp 00000000 08:05 1440096 /lib/ld-2.11.1.so
0048c000-0048d000 r--p 0001a000 08:05 1440096 /lib/ld-2.11.1.so
0048d000-0048e000 rw-p 0001b000 08:05 1440096 /lib/ld-2.11.1.so
00905000-0090c000 r-xp 00000000 08:05 1569989 /lib/tls/i686/cmov/librt-2.11.1.so
0090c000-0090d000 r--p 00006000 08:05 1569989 /lib/tls/i686/cmov/librt-2.11.1.so
0090d000-0090e000 rw-p 00007000 08:05 1569989 /lib/tls/i686/cmov/librt-2.11.1.so
08048000-0804b000 r-xp 00000000 08:05 1458241 /home/neverMind/Desktop/SO-TP2/MMF/MMF_inverter
0804b000-0804c000 r--p 00002000 08:05 1458241 /home/neverMind/Desktop/SO-TP2/MMF/MMF_inverter
0804c000-0804d000 rw-p 00003000 08:05 1458241 /home/neverMind/Desktop/SO-TP2/MMF/MMF_inverter
093a0000-093c1000 rw-p 00000000 00:00 0 [heap]
b7700000-b7721000 rw-p 00000000 00:00 0
b7721000-b7800000 ---p 00000000 00:00 0
b781c000-b7855000 rw-s 00000000 08:05 1458172 /home/neverMind/Desktop/SO-TP2/MMF/out.ppm
b7855000-b7857000 rw-p 00000000 00:00 0
b7862000-b7863000 rw-s 00000000 00:04 52069041 /SYSV00000000 (deleted)Aborted
Here is the code (run as ./invert input_filename.ppm output_filename.ppm) it has to be ppm:
main
functions c file
header file
makefile
You can test it with this for example: ppm image with p6 header
I'm only mapping the file in the master process, before spawn children and make each child invert a row on that mapped file. Is this correct?
Among other things, you are closing your file handles twice. Run your program under valgrind, as Drakosha suggested.
I'm tackling a trivial buffer overflow (yes, exploitation; but unrelated to the problem) I'm trying to figure out the fields in the memory map, when GCC's stack protector is enabled. As an illustration:
$ ./overflow
*** stack smashing detected ***: ./overflow terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7f67da8]
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7f67d60]
./overflow[0x804845c]
[0x41414141]
======= Memory map: ========
08048000-08049000 r-xp 00000000 08:06 3704767 /home/hatred/w0rk/bugz
08049000-0804a000 r--p 00000000 08:06 3704767 /home/hatred/w0rk/bugz
0804a000-0804b000 rw-p 00001000 08:06 3704767 /home/hatred/w0rk/bugz
0804b000-0806c000 rw-p 0804b000 00:00 0 [heap]
b7e5a000-b7e67000 r-xp 00000000 08:06 368705 /lib/libgcc_s.so.1
b7e67000-b7e68000 r--p 0000c000 08:06 368705 /lib/libgcc_s.so.1
b7e68000-b7e69000 rw-p 0000d000 08:06 368705 /lib/libgcc_s.so.1
b7e69000-b7e6a000 rw-p b7e69000 00:00 0
b7e6a000-b7fc6000 r-xp 00000000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc6000-b7fc7000 ---p 0015c000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc7000-b7fc9000 r--p 0015c000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fc9000-b7fca000 rw-p 0015e000 08:06 386037 /lib/tls/i686/cmov/libc-2.9.so
b7fca000-b7fcd000 rw-p b7fca000 00:00 0
b7fdf000-b7fe1000 rw-p b7fdf000 00:00 0
b7fe1000-b7fe2000 r-xp b7fe1000 00:00 0 [vdso]
b7fe2000-b7ffe000 r-xp 00000000 08:06 368654 /lib/ld-2.9.so
b7ffe000-b7fff000 r--p 0001b000 08:06 368654 /lib/ld-2.9.so
b7fff000-b8000000 rw-p 0001c000 08:06 368654 /lib/ld-2.9.so
bffeb000-c0000000 rw-p bffeb000 00:00 0 [stack]
Aborted
So, as you can see; There's the backtrace, and then there's the memory map, with 5 fields, and then an optional sixth one which may include a .so.1 (shared libraries?) I'm asking about what these fields are, and what they mean, like the hex fields, and what rw-p means, etc.
I've gone on google and searched but nothing like this comes up.
Thanks.
Check out the man page for the /proc filesystem, it has all the info you need:
/proc/[number]/maps
A file containing the currently mapped memory regions and their access
permissions.
The format is:
address perms offset dev inode pathname
08048000-08056000 r-xp 00000000 03:0c 64593 /usr/sbin/gpm
08056000-08058000 rw-p 0000d000 03:0c 64593 /usr/sbin/gpm
08058000-0805b000 rwxp 00000000 00:00 0
40000000-40013000 r-xp 00000000 03:0c 4165 /lib/ld-2.2.4.so
40013000-40015000 rw-p 00012000 03:0c 4165 /lib/ld-2.2.4.so
4001f000-40135000 r-xp 00000000 03:0c 45494 /lib/libc-2.2.4.so
40135000-4013e000 rw-p 00115000 03:0c 45494 /lib/libc-2.2.4.so
4013e000-40142000 rw-p 00000000 00:00 0
bffff000-c0000000 rwxp 00000000 00:00 0
where address is the address space in the process that it occupies, perms
is a set of permissions:
r = read
w = write
x = execute
s = shared
p = private (copy on write)
offset is the offset into the file/whatever, dev is the device
(major:minor), and inode is the inode
on that device. 0 indicates that no
inode is associated with the memory
region, as the case would be with bss.