Analizując core dumpa w gdb mam taki problem:
(gdb) x/x $rbx
0x7f5264621d80: Cannot access memory at address 0x7f5264621d80
Jak stwierdzic czy ten adres (wskazywany przez rbx) jest w dobrej czesci przestrzeni adresowej (nie jadra) ?
Ewentualnie co jeszcze moze byc przyczyna problemow z dostepem do tego adresu ?
Dodam ze jak patrze na przykladowyproces za pomoca less /proc/<pid>/map
i mam cos takiego:
00400000-00401000 r-xp 00000000 fd:01 133293 /rtr/rtr/testy_moje/a.out
00600000-00601000 r--p 00000000 fd:01 133293 /rtr/rtr/testy_moje/a.out
00601000-00602000 rw-p 00001000 fd:01 133293 /rtr/rtr/testy_moje/a.out
3387c00000-3387c21000 r-xp 00000000 fd:01 393360 /usr/lib64/ld-2.17.so
3387e20000-3387e21000 r--p 00020000 fd:01 393360 /usr/lib64/ld-2.17.so
3387e21000-3387e22000 rw-p 00021000 fd:01 393360 /usr/lib64/ld-2.17.so
3387e22000-3387e23000 rw-p 00000000 00:00 0
3388000000-33881b6000 r-xp 00000000 fd:01 393388 /usr/lib64/libc-2.17.so
33881b6000-33883b5000 ---p 001b6000 fd:01 393388 /usr/lib64/libc-2.17.so
33883b5000-33883b9000 r--p 001b5000 fd:01 393388 /usr/lib64/libc-2.17.so
33883b9000-33883bb000 rw-p 001b9000 fd:01 393388 /usr/lib64/libc-2.17.so
33883bb000-33883c0000 rw-p 00000000 00:00 0
3388c00000-3388d01000 r-xp 00000000 fd:01 393734 /usr/lib64/libm-2.17.so
3388d01000-3388f00000 ---p 00101000 fd:01 393734 /usr/lib64/libm-2.17.so
3388f00000-3388f01000 r--p 00100000 fd:01 393734 /usr/lib64/libm-2.17.so
3388f01000-3388f02000 rw-p 00101000 fd:01 393734 /usr/lib64/libm-2.17.so
338a000000-338a015000 r-xp 00000000 fd:01 394555 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
338a015000-338a214000 ---p 00015000 fd:01 394555 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
338a214000-338a215000 r--p 00014000 fd:01 394555 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
338a215000-338a216000 rw-p 00015000 fd:01 394555 /usr/lib64/libgcc_s-4.8.3-20140911.so.1
338b800000-338b8e6000 r-xp 00000000 fd:01 394561 /usr/lib64/libstdc++.so.6.0.19
338b8e6000-338bae5000 ---p 000e6000 fd:01 394561 /usr/lib64/libstdc++.so.6.0.19
338bae5000-338baed000 r--p 000e5000 fd:01 394561 /usr/lib64/libstdc++.so.6.0.19
338baed000-338baef000 rw-p 000ed000 fd:01 394561 /usr/lib64/libstdc++.so.6.0.19
338baef000-338bb04000 rw-p 00000000 00:00 0
7fcdc8ed1000-7fcdc8ed6000 rw-p 00000000 00:00 0
7fcdc8efb000-7fcdc8efc000 rw-p 00000000 00:00 0
7fff09116000-7fff09137000 rw-p 00000000 00:00 0 [stack]
7fff091fe000-7fff09200000 r-xp 00000000 00:00 0 [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
To w ktorym obszarze jest ten moj adres z wczesniejszego postu ?? miedzy 338bb04000, a 7fcdc8ed1000 ?? Co z ta dziura adresow ?
00601000-00602000 rw-p 00001000 fd:01 133293 tu się kończy twoja aplikacja, adres wywało jest wyżej, w innej bibliotece.
<co nie znaczy, że biblioteka jest zryta>
Wywałka jest gdzieś w _int_malloc z biblioteki std, pytanie czy adres tego rejetru j est sensowny czy wykracza poza zakres przestrzeni adresowej do jakiej moge sie odwolywac ? Chodzi mi o podzial pamieci procesu na obszar dl ausera i dla kernela