I am observing segmentation fault randomly when doing a ps of a particular process id. THe process to which the pid is pointing was up and running during the time ps {pid} was executed
Backtrace :
(gdb) bt
#0 reset_global () at ps/global.c:362
#1 0x0000000000402456 in main (argc=2, argv=0x7ffe02d33fa8) at ps/display.c:578 (gdb)
at ps/global.c:362 there is a call to look_up_our_self(&p);
359 void reset_global(void){
360 static proc_t p;
361 reset_selection_list();
362 look_up_our_self(&p);
363 set_screen_size();
364 set_personality();
365 int fd;
366 char *buf[BUFFSIZE];
disassemble out put.
gdb) disassemble
0x000000000040315a <+74>: callq 0x401930 <free#plt>
0x000000000040315f <+79>: test %rbp,%rbp
0x0000000000403162 <+82>: jne 0x403148 <reset_global+56>
0x0000000000403164 <+84>: lea 0x10(%rsp),%rbx
0x0000000000403169 <+89>: mov $0x635860,%edi
0x000000000040316e <+94>: movq $0x0,0x21253f(%rip) # 0x6156b8 <selection_list>
=> 0x0000000000403179 <+105>: callq 0x401a60 <look_up_our_self#plt>
0x000000000040317e <+110>: xor %eax,%eax
0x0000000000403180 <+112>: mov %rbx,%rdx
0x0000000000403183 <+115>: mov $0x5413,%esi
0x0000000000403188 <+120>: mov $0x1,%edi
0x000000000040318d <+125>: callq 0x4017f0 <ioctl#plt>
0x0000000000403192 <+130>: cmp $0xffffffffffffffff,%eax
Registers
(gdb) info registers
rax 0xdeadbeef 3735928559
rbx 0x7ffe02cb3d50 140728945294672
rcx 0x0 0
rdx 0x0 0
rsi 0x7ffe02d33ce0 140728945818848
rdi 0x635860 6510688
rbp 0x7ffe02d33df0 0x7ffe02d33df0
rsp 0x7ffe02cb3d40 0x7ffe02cb3d40
r8 0x0 0
r9 0x1 1
r10 0x8 8
r11 0x206 518
r12 0x2 2
r13 0x7ffe02d33fa8 140728945819560
r14 0x0 0
r15 0x0 0
rip 0x403179 0x403179 <reset_global+105>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
(gdb)
update: maps output:
00400000-00416000 r-xp 00000000 00:11 6116
/bin/ps 00615000-00616000 rw-p 00015000 00:11 6116
/bin/ps 00616000-00636000 rw-p 00000000 00:00 0 7ffe0258d000-7ffe026e1000 r-xp 00000000 00:11 8166
/lib64/libc-2.11.1.so 7ffe026e1000-7ffe028e1000 ---p 00154000 00:11 8166 /lib64/libc-2.11.1.so 7ffe028e1000-7ffe028e5000 r--p 00154000 00:11 8166
/lib64/libc-2.11.1.so 7ffe028e5000-7ffe028e6000 rw-p 00158000 00:11 8166 /lib64/libc-2.11.1.so 7ffe028e6000-7ffe028eb000 rw-p 00000000 00:00 0 7ffe028eb000-7ffe028ed000 r-xp 00000000 00:11 8175
/lib64/libdl-2.11.1.so 7ffe028ed000-7ffe02aed000 ---p 00002000 00:11 8175 /lib64/libdl-2.11.1.so 7ffe02aed000-7ffe02aee000 r--p 00002000 00:11 8175
/lib64/libdl-2.11.1.so 7ffe02aee000-7ffe02aef000 rw-p 00003000 00:11 8175 /lib64/libdl-2.11.1.so 7ffe02aef000-7ffe02afe000 r-xp 00000000 00:11 8213
/lib64/libproc-3.2.8.so 7ffe02afe000-7ffe02cfe000 ---p 0000f000 00:11 8213 /lib64/libproc-3.2.8.so 7ffe02cfe000-7ffe02cff000 rw-p 0000f000 00:11 8213
/lib64/libproc-3.2.8.so 7ffe02cff000-7ffe02d13000 rw-p 00000000 00:00 0 7ffe02d14000-7ffe02d35000 rw-p 00000000 00:00 0
[stack] 7ffe02d7f000-7ffe02d80000 r-xp 00000000 00:00 0
[vdso] 7ffe02eaa000-7ffe02ec8000 r-xp 00000000 00:11 8156
/lib64/ld-2.11.1.so 7ffe030b9000-7ffe030bc000 rw-p 00000000 00:00 0 7ffe030c6000-7ffe030c7000 rw-p 00000000 00:00 0 7ffe030c7000-7ffe030c8000 r--p 0001d000 00:11 8156
/lib64/ld-2.11.1.so 7ffe030c8000-7ffe030c9000 rw-p 0001e000 00:11 8156 /lib64/ld-2.11.1.so 7ffe030c9000-7ffe030ca000 rw-p 00000000 00:00 0 ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
Please find the proc/map file contents below for the above segmentation fault: On behalf of Guruswamy Basavaiah
00400000-00416000 r-xp 00000000 00:11 6116 /bin/ps
00615000-00616000 rw-p 00015000 00:11 6116 /bin/ps
00616000-00636000 rw-p 00000000 00:00 0
7ffe0258d000-7ffe026e1000 r-xp 00000000 00:11 8166 /lib64/libc-2.11.1.so
7ffe026e1000-7ffe028e1000 ---p 00154000 00:11 8166 /lib64/libc-2.11.1.so
7ffe028e1000-7ffe028e5000 r--p 00154000 00:11 8166 /lib64/libc-2.11.1.so
7ffe028e5000-7ffe028e6000 rw-p 00158000 00:11 8166 /lib64/libc-2.11.1.so
7ffe028e6000-7ffe028eb000 rw-p 00000000 00:00 0
7ffe028eb000-7ffe028ed000 r-xp 00000000 00:11 8175 /lib64/libdl-2.11.1.so
7ffe028ed000-7ffe02aed000 ---p 00002000 00:11 8175 /lib64/libdl-2.11.1.so
7ffe02aed000-7ffe02aee000 r--p 00002000 00:11 8175 /lib64/libdl-2.11.1.so
7ffe02aee000-7ffe02aef000 rw-p 00003000 00:11 8175 /lib64/libdl-2.11.1.so
7ffe02aef000-7ffe02afe000 r-xp 00000000 00:11 8213 /lib64/libproc-3.2.8.so
7ffe02afe000-7ffe02cfe000 ---p 0000f000 00:11 8213 /lib64/libproc-3.2.8.so
7ffe02cfe000-7ffe02cff000 rw-p 0000f000 00:11 8213 /lib64/libproc-3.2.8.so
7ffe02cff000-7ffe02d13000 rw-p 00000000 00:00 0
7ffe02d14000-7ffe02d35000 rw-p 00000000 00:00 0 [stack]
7ffe02d7f000-7ffe02d80000 r-xp 00000000 00:00 0 [vdso]
7ffe02eaa000-7ffe02ec8000 r-xp 00000000 00:11 8156 /lib64/ld-2.11.1.so
7ffe030b9000-7ffe030bc000 rw-p 00000000 00:00 0
7ffe030c6000-7ffe030c7000 rw-p 00000000 00:00 0
7ffe030c7000-7ffe030c8000 r--p 0001d000 00:11 8156 /lib64/ld-2.11.1.so
7ffe030c8000-7ffe030c9000 rw-p 0001e000 00:11 8156 /lib64/ld-2.11.1.so
7ffe030c9000-7ffe030ca000 rw-p 00000000 00:00 0
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Related
I'm trying to study how Linux would behave if I were to allocate a 10 bytes of memory at every page boundary for a total of ten pages. Here is the program I could come up with:
1 #include <stdlib.h>$
2 #include <stdio.h>$
3 #include <time.h>$
4 #include <unistd.h>$
5 #include <string.h>$
6 $
7 #define PAGESIZE getpagesize()$
8 int main () {$
9 int *ArrP[10] = {NULL};$
10 int pgSz = PAGESIZE;$
11 int randnum;$
12 $
13
14 for (int i = 0; i < (sizeof(ArrP)/sizeof(int*)); i++) {$
15 if(posix_memalign((void **)&ArrP[i], pgSz, 10)) {$
16 perror("error getting page aligned mem: ");$
17 exit(1);$
18 }$
19 else$
20 printf("ArrP[%d] = %lu\n", i, ArrP[i]);$
21 }$
22 $
23 srand(time(0));$
24 while(1) {$
25 for (int i = 0; i <(sizeof(ArrP)/sizeof(int*)); i++) {$
26 randnum = rand();$
27 memcpy(ArrP[i], &randnum, sizeof(int));$
28 }$
29 }$
30 return 0;$
31 }$
However when I run it, the /proc/pid/maps file shows a heap size of 0.
here's the content of that file:
555555554000-555555555000 r--p 00000000 08:01 1966744 /home/AB1/ProgPractice/InternalFragmentation
555555555000-555555556000 r-xp 00001000 08:01 1966744 /home/AB1/ProgPractice/InternalFragmentation
555555556000-555555557000 r--p 00002000 08:01 1966744 /home/AB1/ProgPractice/InternalFragmentation
555555557000-555555558000 r--p 00002000 08:01 1966744 /home/AB1/ProgPractice/InternalFragmentation
555555558000-555555559000 rw-p 00003000 08:01 1966744 /home/AB1/ProgPractice/InternalFragmentation
555555559000-55555557a000 rw-p 00000000 00:00 0 [heap]
7ffff7dd8000-7ffff7dfd000 r--p 00000000 08:01 2234184 /usr/lib/libc-2.30.so
7ffff7dfd000-7ffff7f4a000 r-xp 00025000 08:01 2234184 /usr/lib/libc-2.30.so
7ffff7f4a000-7ffff7f94000 r--p 00172000 08:01 2234184 /usr/lib/libc-2.30.so
7ffff7f94000-7ffff7f95000 ---p 001bc000 08:01 2234184 /usr/lib/libc-2.30.so
7ffff7f95000-7ffff7f98000 r--p 001bc000 08:01 2234184 /usr/lib/libc-2.30.so
7ffff7f98000-7ffff7f9b000 rw-p 001bf000 08:01 2234184 /usr/lib/libc-2.30.so
7ffff7f9b000-7ffff7fa1000 rw-p 00000000 00:00 0
7ffff7fce000-7ffff7fd1000 r--p 00000000 00:00 0 [vvar]
7ffff7fd1000-7ffff7fd2000 r-xp 00000000 00:00 0 [vdso]
7ffff7fd2000-7ffff7fd4000 r--p 00000000 08:01 2234140 /usr/lib/ld-2.30.so
7ffff7fd4000-7ffff7ff3000 r-xp 00002000 08:01 2234140 /usr/lib/ld-2.30.so
7ffff7ff3000-7ffff7ffb000 r--p 00021000 08:01 2234140 /usr/lib/ld-2.30.so
7ffff7ffc000-7ffff7ffd000 r--p 00029000 08:01 2234140 /usr/lib/ld-2.30.so
7ffff7ffd000-7ffff7ffe000 rw-p 0002a000 08:01 2234140 /usr/lib/ld-2.30.so
7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0 [vsyscall]
I've disabled ASLR but it doesn't make a difference. Any suggestions
I'm very new to C programming and investigating continuously increasing RSS size. The suspicion is there is some memory leak. I looked at the /proc/<pid>/maps and found the following:
f8000000-fb180000 rw-p 00000000 00:00 0
fb180000-fd580000 ---p 00000000 00:00 0
fd580000-fdc80000 rw-p 00000000 00:00 0
fdc80000-100000000 ---p 00000000 00:00 0
100000000-1005a0000 rw-p 00000000 00:00 0
1005a0000-140000000 ---p 00000000 00:00 0
7fb45d1dd000-7fb45d1e0000 ---p 00000000 00:00 0
7fb45e0ec000-7fb45e0ef000 ---p 00000000 00:00 0
7fb45e0ef000-7fb45e1ed000 rw-p 00000000 00:00 0
7fb45e1ed000-7fb45e1f0000 ---p 00000000 00:00 0
7fb45e1f0000-7fb45e2ee000 rw-p 00000000 00:00 0
7fb45e2ee000-7fb45e2f1000 ---p 00000000 00:00 0
7fb45e2f1000-7fb45e3ef000 rw-p 00000000 00:00 0
7fb45e3ef000-7fb45e3f2000 ---p 00000000 00:00 0
7fb45e3f2000-7fb45e4f0000 rw-p 00000000 00:00 0
7fb45e4f0000-7fb45e4f3000 ---p 00000000 00:00 0
7fb45e4f3000-7fb45e5f1000 rw-p 00000000 00:00 0
7fb45e5f1000-7fb45e5f4000 ---p 00000000 00:00 0
7fb45e5f4000-7fb45e6f2000 rw-p 00000000 00:00 0
7fb45e6f2000-7fb45e6f5000 ---p 00000000 00:00 0
7fb45e6f5000-7fb45e7f3000 rw-p 00000000 00:00 0
7fb45e7f3000-7fb45e7f6000 ---p 00000000 00:00 0
7fb45e7f6000-7fb45e8f4000 rw-p 00000000 00:00 0
7fb45e8f4000-7fb45e8f7000 ---p 00000000 00:00 0
//Tons of the similar entries...
7fb71652b000-7fb71652c000 rw-p 0001a000 08:01 2187 /lib/x86_64-linux-gnu/libpthread-2.27.so
7fb716568000-7fb71656f000 r--s 00000000 08:01 5020 /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
7fb716759000-7fb71675a000 rw-p 00000000 00:00 0
7ffc5f781000-7ffc5f7a2000 rw-p 00000000 00:00 0 [stack]
7ffc5f7c7000-7ffc5f7ca000 r--p 00000000 00:00 0 [vvar]
7ffc5f7ca000-7ffc5f7cc000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
The thing that I noticed was that the vast majority of /proc/<pid>/maps were entries like:
7fb45e7f3000-7fb45e7f6000 ---p 00000000 00:00 0
What does this mean? Doesn't it mean that system allocator release the memory it acquires?
Is there a way to examine the memory content at address, e.g. 7fb45e5f4000-7fb45e6f2000 at run-time?
I tried to attach to the running process with gdb and looked at the memory.
(gdb) x /1xg 0x7fb45e1ed000
0x5e1ed000: Cannot access memory at address 0x5e1ed000
Entries like
7fb45e0ec000-7fb45e0ef000 ---p 00000000 00:00 0
7fb45e0ef000-7fb45e1ed000 rw-p 00000000 00:00 0
look like thread stacks and their associated guard pages.
It looks like you create a lot of threads, but neither reap them via pthread_join(), or detach them via pthread_detach() (or create them in detached state).
Non-detached threads must be reaped to return their resources (stack, specifically) to the OS.
When sbrk() returns a pointer to an address that is the beginning of the heap, are the addresses ascending or descending? For example, if I had a 10 byte heap from addresses 1 to 10, would sbrk() return a pointer to address 10 or 1?
On a similar note, heap addresses tend to grow "down"... but how can I figure out whether the addresses increase or decrease on my computer?
The man page on Mac OS X says:
The brk and sbrk functions are historical curiosities left over from earlier days before the
advent of virtual memory management.
The current value of the program break is reliably returned by sbrk(0).
The sbrk function returns a pointer to the base of the
new storage if successful; otherwise -1 with errno set to indicate why the allocation failed.
Suppose you use:
void *base = sbrk(1024);
After that, assuming no error, base will contain the starting address of a 1024 byte (minimum) block of memory; (char *)base + 1024 will be beyond what you requested, though it may still be valid since the page size may be larger than 1024.
It doesn't say directly whether a subsequent allocation will have a larger or smaller address than another. However, it is likely to be in increasing order of addresses.
The brk() function sets the break or lowest address of a
process's data segment (uninitialized data) to addr (immediately above bss). Data addressing
is restricted between addr and the lowest stack pointer to the stack segment. Memory is allocated by brk in page size pieces; if addr is not evenly divisible by the system page size, it
is increased to the next page boundary.
This implies that the extra space is after the data and bss segments, and grows up towards the stack (which grows downwards in memory). However, relying on that would probably be foolhardy. You'd do best to use sbrk(0) to establish the current end after calling sbrk(extra) to get extra space; this will tell you what you really got and the two addresses tell you where it was made available.
If you are on Linux, you can examine /proc/$PID/maps to see how the virtual address space is utilized for each process.
Sample code: mappingTest.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int foo(int depth) {
char buf[8192];
if (0 == depth)
printf("%p\n", buf);
if (1000 < depth) {
printf("%p\n", buf);
return getchar();
} else {
return 1 + foo(depth + 1);
}
}
int main() {
const size_t SIZE = 1000 * 1000 * 1000;
getchar();
char * const p = malloc(SIZE);
printf("%p\n", p);
getchar();
free(p);
getchar();
foo(0);
return 0;
}
Note: char buf[8192] and recursion of 1000 times assume that the maximum stack size is 8 MB (you can confirm with ulimit -s.)
$ gcc mappingTest.c -o mappingTest -Wall -Wextra -Wno-missing-field-initializers -std=c89 -O0 -g3 && echo OK
OK
$ ./mappingTest
At the 1st getchar(), we see the following memory mappings for the process:
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97469000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6d43000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
We hit Enter and proceed to the 2nd getchar().
I got 0x7f2e5b4dd010 on my terminal as the value of p and it falls within the first anonymous mapping region 7f2e5b4dd000-7f2e96e8a000 in the below listing, but it didin't exist in the above listing.
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e5b4dd000-7f2e96e8a000 rw-p 00000000 00:00 0
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97468000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6d43000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
We hit Enter and proceed to the 3rd getchar().
In the below listing, we see the anonymous mapping region disappeared due to free().
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97468000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6d43000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
We hit Enter and proceed to the 4th getchar() in the deeply nested calls of foo().
I got 0x7fffa6d60ba0 and 0x7fffa6582ff0 on my terminal as the addresses of buf in the 1st and 1001st recursive call of foo(). Both of them fall within the [stack] region (7fffa6582000-7fffa6d64000; 0x7e2000 == 8 MB) now. But note that it was previously 7fffa6d43000-7fffa6d64000; 0x21000 == 132 KB.
$ cat /proc/`pidof mappingTest`/maps
00400000-00401000 r-xp 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00600000-00601000 r--p 00000000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
00601000-00602000 rw-p 00001000 08:05 21687266 /home/nodakai/prog/exp/mappingTest
7f2e96e8a000-7f2e9703f000 r-xp 00000000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9703f000-7f2e9723f000 ---p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e9723f000-7f2e97243000 r--p 001b5000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97243000-7f2e97245000 rw-p 001b9000 08:05 14314431 /lib/x86_64-linux-gnu/libc-2.15.so
7f2e97245000-7f2e9724a000 rw-p 00000000 00:00 0
7f2e9724a000-7f2e9726c000 r-xp 00000000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e97443000-7f2e97446000 rw-p 00000000 00:00 0
7f2e97468000-7f2e9746c000 rw-p 00000000 00:00 0
7f2e9746c000-7f2e9746d000 r--p 00022000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7f2e9746d000-7f2e9746f000 rw-p 00023000 08:05 14314443 /lib/x86_64-linux-gnu/ld-2.15.so
7fffa6582000-7fffa6d64000 rw-p 00000000 00:00 0 [stack]
7fffa6dff000-7fffa6e00000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
You may have more fun with inline assembly like this:
#define PEEK_ESP(reg) \
__asm__ __volatile__ ( \
"movq %%rsp, %0" \
: "=r"(reg) \
)
...
void *p;
PEEK_ESP(p);
During my debugging, I got the following error message.
Alignment trap: my_main (29858) PC=0x00170ad8 Instr=0xe5960008 Address=0x00f28daa FSR 0x0f3
I've looked around a bit and found a lot of information on this (broken link) real-time embedded website .
So now I know what PC and Instr refers to, but I still haven't found anything about the Address and FSR part.
What is FSR? What address does Address refer to? According to proc/xxxx/maps that address is even outside the scope of my program. Does anybody know what the last two items mean? I need information on these to solve this alignment problem.
MAP output
00008000-001fe000 r-xp 00000000 03:02 16204 /home/myuser/my_main
00205000-00248000 rw-p 001f5000 03:02 16204 /home/myuser/my_main
00248000-00299000 rwxp 00248000 00:00 0
40000000-40018000 r-xp 00000000 03:01 2095 /lib/ld-2.3.3.so
40018000-4001b000 rw-p 40018000 00:00 0
4001f000-40020000 r--p 00017000 03:01 2095 /lib/ld-2.3.3.so
40020000-40021000 rw-p 00018000 03:01 2095 /lib/ld-2.3.3.so
40021000-40023000 r-xp 00000000 03:01 15724 /usr/lib/libem7.so.1.0.1
40023000-40029000 ---p 00002000 03:01 15724 /usr/lib/libem7.so.1.0.1
40029000-4002b000 rw-p 00000000 03:01 15724 /usr/lib/libem7.so.1.0.1
4002b000-40031000 r-xp 00000000 03:01 2057 /lib/tls/librt-2.3.3.so
40031000-40033000 ---p 00006000 03:01 2057 /lib/tls/librt-2.3.3.so
40033000-40038000 rw-p 00000000 03:01 2057 /lib/tls/librt-2.3.3.so
40038000-40039000 r--p 00005000 03:01 2057 /lib/tls/librt-2.3.3.so
40039000-4003a000 rw-p 00006000 03:01 2057 /lib/tls/librt-2.3.3.so
4003a000-4004a000 r-xp 00000000 03:01 2060 /lib/tls/libpthread-2.3.3.so
4004a000-40051000 rw-p 00008000 03:01 2060 /lib/tls/libpthread-2.3.3.so
40051000-40052000 r--p 0000f000 03:01 2060 /lib/tls/libpthread-2.3.3.so
40052000-40053000 rw-p 00010000 03:01 2060 /lib/tls/libpthread-2.3.3.so
40053000-40055000 rw-p 40053000 00:00 0
40055000-4010e000 r-xp 00000000 03:01 15703 /usr/lib/libstdc++.so.6.0.3
4010e000-40115000 ---p 000b9000 03:01 15703 /usr/lib/libstdc++.so.6.0.3
40115000-40119000 rw-p 000b8000 03:01 15703 /usr/lib/libstdc++.so.6.0.3
40119000-4011f000 rw-p 40119000 00:00 0
4011f000-401b7000 r-xp 00000000 03:01 2076 /lib/tls/libm-2.3.3.so
401b7000-401be000 rw-p 00090000 03:01 2076 /lib/tls/libm-2.3.3.so
401be000-401bf000 r--p 00097000 03:01 2076 /lib/tls/libm-2.3.3.so
401bf000-401c0000 rw-p 00098000 03:01 2076 /lib/tls/libm-2.3.3.so
401c0000-401c8000 r-xp 00000000 03:01 2005 /lib/libgcc_s.so.1
401c8000-401c9000 rw-p 00008000 03:01 2005 /lib/libgcc_s.so.1
401c9000-402cb000 r-xp 00000000 03:01 2078 /lib/tls/libc-2.3.3.so
402cb000-402d1000 ---p 00102000 03:01 2078 /lib/tls/libc-2.3.3.so
402d1000-402d2000 rw-p 00100000 03:01 2078 /lib/tls/libc-2.3.3.so
402d2000-402d4000 r--p 00101000 03:01 2078 /lib/tls/libc-2.3.3.so
402d4000-402d6000 rw-p 00103000 03:01 2078 /lib/tls/libc-2.3.3.so
402d6000-402d8000 rw-p 402d6000 00:00 0
402d8000-402e5000 rw-s 00000000 00:07 0 /SYSV12345678 (deleted)
402e5000-402e6000 ---p 402e5000 00:00 0
402e6000-402f5000 rwxp 402e6000 00:00 0
403c1000-4049d000 rw-p 403c1000 00:00 0
7efeb000-7f000000 rwxp 7efeb000 00:00 0
PC=0x00170ad8
This is telling you the current value of the program counter, it can be used to determine which instruction in your program is causing the trap. If you’re on ARM as I think you are, this is actually the current instruction plus 8, so the instruction causing the trap is located at 0x00170ad0.
Instr=0xe5960008
This is the encoding of the faulting instruction. If this is on ARM, that instruction is ldr r0, [r6, #8]
Address=0x00f28daa
This is telling you the address from which your program attempted to load, causing the fault. Assuming everything else so far is correct, this is r6 + 8, so r6 held 0x00f28da2 at the time of the fault.
FSR 0xf3
This is the value held in the fault status register. It tells you what fault occurred. This particular value is an older encoding (pre-ARMv7) for an Alignment fault.
Most likely your CPU does not support reads/writes from/to memory of values at misaligned addresses. If you're accessing a 4-byte variable, then clearly Address=0x00f28daa isn't a multiple of 4. Only single bytes can be read/written at arbitrarily aligned addresses.
That article explains it well.
I'm trying to mmap a file, and it seems to succeed but when I access it, I get an SIGBUS error.
Code:
int main(int argc, char* argv[]) {
int pid = getpid();
char cmd [1024];
int file;
if (argc != 2) {
printf("Wrong arguments\n");
return 1;
}
printf("%s", argv[1]);
int numpages = atoi(argv[1]);
sprintf(cmd, "cat /proc/%d/maps", pid);
system(cmd);
long page_size = sysconf(_SC_PAGESIZE);
file = open(argv[1], O_RDWR, (mode_t)0600);
ftruncate(file, page_size * numpages);
if(file == -1) {
perror("file open failed!\n");
return 1;
}
printf("\n\n mapping file - numpages: %d \n\n", numpages);
printf("mapping %ld KB\n", page_size * numpages/1024);
int* mapped_file = mmap(0, page_size * numpages, PROT_READ | PROT_WRITE, MAP_PRIVATE, file, 0 );
if (mapped_file == MAP_FAILED) {
perror("Map failed");
return 1;
}
printf("mapped file at %p\n\n", mapped_file);
int* current_pos = mapped_file;
system(cmd);
int j;
for (j=0; j<numpages; j++) {
printf("%d ", *current_pos);
current_pos += page_size/4;
}
if (munmap (mapped_file, page_size * numpages) == -1) {
perror ("munmap");
return 1;
}
if (close(file) == -1) {
perror("close");
return 1;
}
return 0;
}
Output:
(gdb) run 64
Starting program: /home/jords/engcode/workspace/SE370Assignment3/A3Program3 64
00400000-00401000 r-xp 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00600000-00601000 r--p 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00601000-00602000 rw-p 00001000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
7ffff7a48000-7ffff7bd2000 r-xp 00000000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7bd2000-7ffff7dd1000 ---p 0018a000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7dd1000-7ffff7dd5000 r--p 00189000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7dd5000-7ffff7dd6000 rw-p 0018d000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7dd6000-7ffff7ddc000 rw-p 00000000 00:00 0
7ffff7ddc000-7ffff7dfd000 r-xp 00000000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7ffff7fd0000-7ffff7fd3000 rw-p 00000000 00:00 0
7ffff7ff8000-7ffff7ffb000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00020000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7ffff7ffd000-7ffff7fff000 rw-p 00021000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
64
mapping file - numpages: 64
mapping 256 KB
mapped file at 0x7ffff7ff4000
00400000-00401000 r-xp 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00600000-00601000 r--p 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00601000-00602000 rw-p 00001000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
7ffff7a48000-7ffff7bd2000 r-xp 00000000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7bd2000-7ffff7dd1000 ---p 0018a000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7dd1000-7ffff7dd5000 r--p 00189000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7dd5000-7ffff7dd6000 rw-p 0018d000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7ffff7dd6000-7ffff7ddc000 rw-p 00000000 00:00 0
7ffff7ddc000-7ffff7dfd000 r-xp 00000000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7ffff7fd0000-7ffff7fd3000 rw-p 00000000 00:00 0
7ffff7ff4000-7ffff7ff8000 rw-p 00000000 08:03 3288973 /home/jords/engcode/workspace/SE370Assignment3/64
7ffff7ff8000-7ffff7ffb000 rw-p 00000000 00:00 0
7ffff7ffb000-7ffff7ffc000 r-xp 00000000 00:00 0 [vdso]
7ffff7ffc000-7ffff7ffd000 r--p 00020000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7ffff7ffd000-7ffff7fff000 rw-p 00021000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0 [stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
Program received signal SIGBUS, Bus error.
0x0000000000400abb in main (argc=2, argv=0x7fffffffe058) at A3Program3.c:49
49 printf("%d", mapped_file[0]);
(gdb)
It's confusing me, since you can clearly see in the maps output that the file has been mapped and the address is correct - but it gives an error whenever I try to access it.
EDIT: Valgrind:
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
==16295==
==16295== Process terminating with default action of signal 7 (SIGBUS)
==16295== Non-existent physical address at address 0x4024000
==16295== at 0x400AB7: main (A3Program3.c:49)
==16295==
Update: So I have stopped it crashing now (thanks :)) with the ftruncate call, but it's printing all zeros:
jords#jords-desktop ~/engcode/workspace/SE370Assignment3 (master) $ ./A3Program3 64
00400000-00401000 r-xp 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00600000-00601000 r--p 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00601000-00602000 rw-p 00001000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
7f96ec7a1000-7f96ec92b000 r-xp 00000000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ec92b000-7f96ecb2a000 ---p 0018a000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ecb2a000-7f96ecb2e000 r--p 00189000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ecb2e000-7f96ecb2f000 rw-p 0018d000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ecb2f000-7f96ecb35000 rw-p 00000000 00:00 0
7f96ecb35000-7f96ecb56000 r-xp 00000000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7f96ecd2a000-7f96ecd2d000 rw-p 00000000 00:00 0
7f96ecd52000-7f96ecd55000 rw-p 00000000 00:00 0
7f96ecd55000-7f96ecd56000 r--p 00020000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7f96ecd56000-7f96ecd58000 rw-p 00021000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7fff9be10000-7fff9be31000 rw-p 00000000 00:00 0 [stack]
7fff9bf0b000-7fff9bf0c000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
64
mapping file - numpages: 64
mapping 256 KB
mapped file at 0x7f96eccea000
00400000-00401000 r-xp 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00600000-00601000 r--p 00000000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
00601000-00602000 rw-p 00001000 08:03 3288976 /home/jords/engcode/workspace/SE370Assignment3/A3Program3
7f96ec7a1000-7f96ec92b000 r-xp 00000000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ec92b000-7f96ecb2a000 ---p 0018a000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ecb2a000-7f96ecb2e000 r--p 00189000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ecb2e000-7f96ecb2f000 rw-p 0018d000 00:10 8103 /lib/x86_64-linux-gnu/libc-2.13.so
7f96ecb2f000-7f96ecb35000 rw-p 00000000 00:00 0
7f96ecb35000-7f96ecb56000 r-xp 00000000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7f96eccea000-7f96ecd2a000 rw-p 00000000 08:03 3288973 /home/jords/engcode/workspace/SE370Assignment3/64
7f96ecd2a000-7f96ecd2d000 rw-p 00000000 00:00 0
7f96ecd52000-7f96ecd55000 rw-p 00000000 00:00 0
7f96ecd55000-7f96ecd56000 r--p 00020000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7f96ecd56000-7f96ecd58000 rw-p 00021000 00:10 8090 /lib/x86_64-linux-gnu/ld-2.13.so
7fff9be10000-7fff9be31000 rw-p 00000000 00:00 0 [stack]
7fff9bf0b000-7fff9bf0c000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
I think this is because the file is not being read correctly, so all I'm reading is padded zeros. But I'm not sure why that would be
Update, worked it out, it was actually reading the file correctly I was just making a mistake in terms of how to read it. Thanks everyone
The problem is that you open the file with O_TRUNC which truncates it, and since mmap can only map the existing contents of a file it will give you a sigbus. Use truncate() (and friends) to truncate the file to the correct size before mapping it.
From mmap's man page:
SIGBUS Attempted access to a portion of the buffer that does not correspond to the file (for example, beyond the end of the file, including the case where another process has truncated the file).
There's a bug, but it won't explain the crash in mapped_file[0].
sysconf(_SC_PAGESIZE) gives you the page size in bytes.
At each iteration of current_pos += page_size you're incrementing your pointer by sysconf(_SC_PAGESIZE)*sizeof(int) so you quickly get outside the mapped region.
Also, the page_size * 4 in mmap looks questionable: surely num_pages ought to come into the equation?