Address ranges reserved by gdb?
I have a program that mmaps memory at higher addresses using MAP_FIXED at TASK_SIZE - PAGE_SIZE.
This program runs fine if I execute it, but if I run it with gdb, it segfaults just after the mmap. Also at this point, the gdb state seems to be completely corrupted and it appears that the execution reaches an address range filled with 0's (could be from the new mappings just created).
Does gdb use this address range in the running process? Have I cleared out some of gdb's state? Is this address range documented somewhere?
Following is my call to mmap and the address calculation -
#define TASK_SIZE64 (0x800000000000UL - 4096)
#define TASK_SIZE TASK_SIZE64
#define PAGE_OFFSET (void*)TASK_SIZE
...
char *load_address = PAGE_OFFSET - file_size_aligned;
if(load_address != mmap(load_address, file_size_aligned, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0)){
err("Failed to allocate memory for raw_binary with: %dn", errno);
return -1;
}
file_size_aligned comes to a PAGE_SIZE. This is one of the allocations. There is one more that starts from load_address and allocates few more pages backwards (with PROT_READ and PROT_WRITE only).
c linux gdb
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
|
show 2 more comments
I have a program that mmaps memory at higher addresses using MAP_FIXED at TASK_SIZE - PAGE_SIZE.
This program runs fine if I execute it, but if I run it with gdb, it segfaults just after the mmap. Also at this point, the gdb state seems to be completely corrupted and it appears that the execution reaches an address range filled with 0's (could be from the new mappings just created).
Does gdb use this address range in the running process? Have I cleared out some of gdb's state? Is this address range documented somewhere?
Following is my call to mmap and the address calculation -
#define TASK_SIZE64 (0x800000000000UL - 4096)
#define TASK_SIZE TASK_SIZE64
#define PAGE_OFFSET (void*)TASK_SIZE
...
char *load_address = PAGE_OFFSET - file_size_aligned;
if(load_address != mmap(load_address, file_size_aligned, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0)){
err("Failed to allocate memory for raw_binary with: %dn", errno);
return -1;
}
file_size_aligned comes to a PAGE_SIZE. This is one of the allocations. There is one more that starts from load_address and allocates few more pages backwards (with PROT_READ and PROT_WRITE only).
c linux gdb
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
Check this answer: stackoverflow.com/questions/3640095/…. It looks like you need to create function within your program that gives GDB access to those memory regions if you want to inspect them.
– Paul
Nov 25 '18 at 8:48
@Paul I don't think that question is exactly related. I am not mmap'ing the memory in the kernel space. It is inside the user space -TASK_SIZE - PAGE_SIZE. This memory should be accessible by gdb if it needs to.
– Ajay Brahmakshatriya
Nov 25 '18 at 8:52
Ah, good point. Can you include the call you are making tommap? Are you getting an address back from mmap, or you are requesting one?
– Paul
Nov 25 '18 at 8:57
@Paul I am usingMAP_FIXED-- I am passing my own address. Will add the call to mmap.
– Ajay Brahmakshatriya
Nov 25 '18 at 9:11
Does it work if you remove the MAP_FIXED argument? It would be good to know if using GDB with that address space is the cause rather than a GDB issue in general.
– Paul
Nov 25 '18 at 9:29
|
show 2 more comments
I have a program that mmaps memory at higher addresses using MAP_FIXED at TASK_SIZE - PAGE_SIZE.
This program runs fine if I execute it, but if I run it with gdb, it segfaults just after the mmap. Also at this point, the gdb state seems to be completely corrupted and it appears that the execution reaches an address range filled with 0's (could be from the new mappings just created).
Does gdb use this address range in the running process? Have I cleared out some of gdb's state? Is this address range documented somewhere?
Following is my call to mmap and the address calculation -
#define TASK_SIZE64 (0x800000000000UL - 4096)
#define TASK_SIZE TASK_SIZE64
#define PAGE_OFFSET (void*)TASK_SIZE
...
char *load_address = PAGE_OFFSET - file_size_aligned;
if(load_address != mmap(load_address, file_size_aligned, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0)){
err("Failed to allocate memory for raw_binary with: %dn", errno);
return -1;
}
file_size_aligned comes to a PAGE_SIZE. This is one of the allocations. There is one more that starts from load_address and allocates few more pages backwards (with PROT_READ and PROT_WRITE only).
c linux gdb
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
I have a program that mmaps memory at higher addresses using MAP_FIXED at TASK_SIZE - PAGE_SIZE.
This program runs fine if I execute it, but if I run it with gdb, it segfaults just after the mmap. Also at this point, the gdb state seems to be completely corrupted and it appears that the execution reaches an address range filled with 0's (could be from the new mappings just created).
Does gdb use this address range in the running process? Have I cleared out some of gdb's state? Is this address range documented somewhere?
Following is my call to mmap and the address calculation -
#define TASK_SIZE64 (0x800000000000UL - 4096)
#define TASK_SIZE TASK_SIZE64
#define PAGE_OFFSET (void*)TASK_SIZE
...
char *load_address = PAGE_OFFSET - file_size_aligned;
if(load_address != mmap(load_address, file_size_aligned, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_ANONYMOUS | MAP_PRIVATE | MAP_FIXED, -1, 0)){
err("Failed to allocate memory for raw_binary with: %dn", errno);
return -1;
}
file_size_aligned comes to a PAGE_SIZE. This is one of the allocations. There is one more that starts from load_address and allocates few more pages backwards (with PROT_READ and PROT_WRITE only).
c linux gdb
c linux gdb
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
edited Nov 25 '18 at 9:15
Ajay Brahmakshatriya
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
asked Nov 25 '18 at 8:44
Ajay BrahmakshatriyaAjay Brahmakshatriya
6,96531636
6,96531636
Check this answer: stackoverflow.com/questions/3640095/…. It looks like you need to create function within your program that gives GDB access to those memory regions if you want to inspect them.
– Paul
Nov 25 '18 at 8:48
@Paul I don't think that question is exactly related. I am not mmap'ing the memory in the kernel space. It is inside the user space -TASK_SIZE - PAGE_SIZE. This memory should be accessible by gdb if it needs to.
– Ajay Brahmakshatriya
Nov 25 '18 at 8:52
Ah, good point. Can you include the call you are making tommap? Are you getting an address back from mmap, or you are requesting one?
– Paul
Nov 25 '18 at 8:57
@Paul I am usingMAP_FIXED-- I am passing my own address. Will add the call to mmap.
– Ajay Brahmakshatriya
Nov 25 '18 at 9:11
Does it work if you remove the MAP_FIXED argument? It would be good to know if using GDB with that address space is the cause rather than a GDB issue in general.
– Paul
Nov 25 '18 at 9:29
|
show 2 more comments
Check this answer: stackoverflow.com/questions/3640095/…. It looks like you need to create function within your program that gives GDB access to those memory regions if you want to inspect them.
– Paul
Nov 25 '18 at 8:48
@Paul I don't think that question is exactly related. I am not mmap'ing the memory in the kernel space. It is inside the user space -TASK_SIZE - PAGE_SIZE. This memory should be accessible by gdb if it needs to.
– Ajay Brahmakshatriya
Nov 25 '18 at 8:52
Ah, good point. Can you include the call you are making tommap? Are you getting an address back from mmap, or you are requesting one?
– Paul
Nov 25 '18 at 8:57
@Paul I am usingMAP_FIXED-- I am passing my own address. Will add the call to mmap.
– Ajay Brahmakshatriya
Nov 25 '18 at 9:11
Does it work if you remove the MAP_FIXED argument? It would be good to know if using GDB with that address space is the cause rather than a GDB issue in general.
– Paul
Nov 25 '18 at 9:29
Check this answer: stackoverflow.com/questions/3640095/…. It looks like you need to create function within your program that gives GDB access to those memory regions if you want to inspect them.
– Paul
Nov 25 '18 at 8:48
Check this answer: stackoverflow.com/questions/3640095/…. It looks like you need to create function within your program that gives GDB access to those memory regions if you want to inspect them.
– Paul
Nov 25 '18 at 8:48
@Paul I don't think that question is exactly related. I am not mmap'ing the memory in the kernel space. It is inside the user space -
TASK_SIZE - PAGE_SIZE. This memory should be accessible by gdb if it needs to.– Ajay Brahmakshatriya
Nov 25 '18 at 8:52
@Paul I don't think that question is exactly related. I am not mmap'ing the memory in the kernel space. It is inside the user space -
TASK_SIZE - PAGE_SIZE. This memory should be accessible by gdb if it needs to.– Ajay Brahmakshatriya
Nov 25 '18 at 8:52
Ah, good point. Can you include the call you are making to
mmap? Are you getting an address back from mmap, or you are requesting one?– Paul
Nov 25 '18 at 8:57
Ah, good point. Can you include the call you are making to
mmap? Are you getting an address back from mmap, or you are requesting one?– Paul
Nov 25 '18 at 8:57
@Paul I am using
MAP_FIXED -- I am passing my own address. Will add the call to mmap.– Ajay Brahmakshatriya
Nov 25 '18 at 9:11
@Paul I am using
MAP_FIXED -- I am passing my own address. Will add the call to mmap.– Ajay Brahmakshatriya
Nov 25 '18 at 9:11
Does it work if you remove the MAP_FIXED argument? It would be good to know if using GDB with that address space is the cause rather than a GDB issue in general.
– Paul
Nov 25 '18 at 9:29
Does it work if you remove the MAP_FIXED argument? It would be good to know if using GDB with that address space is the cause rather than a GDB issue in general.
– Paul
Nov 25 '18 at 9:29
|
show 2 more comments
1 Answer
1
active
oldest
votes
Does gdb use this address range in the running process?
No.
Have I cleared out some of gdb's state?
No.
Is this address range documented somewhere?
Possibly in kernel sources.
Your program makes invalid assumptions about available address space, and "blows itself up" when run with ASLR turned off (which GDB does by default).
You can confirm this by running your program outside GDB, but with ASLR disabled. It should also crash. Try one of these:
# echo 0 > /proc/sys/kernel/randomize_va_space
or
setarch $(uname -m) -R /path/to/exe
You can also confirm that your program will run under GDB if you enable ASLR:
gdb /path/to/exe
(gdb) set disable-randomization off
(gdb) run
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
Alright, this makes a lot more sense. I actually have to acquire an address range according to some other constraints too. So I am trying not to usemmap(NULL, ...). The address range I had used satisfied the other constraint. I thought this would be free for most processes too. Didn't realize with ASRL turned off, the mapping starts right from the bottom.
– Ajay Brahmakshatriya
Nov 25 '18 at 19:34
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53465930%2faddress-ranges-reserved-by-gdb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Does gdb use this address range in the running process?
No.
Have I cleared out some of gdb's state?
No.
Is this address range documented somewhere?
Possibly in kernel sources.
Your program makes invalid assumptions about available address space, and "blows itself up" when run with ASLR turned off (which GDB does by default).
You can confirm this by running your program outside GDB, but with ASLR disabled. It should also crash. Try one of these:
# echo 0 > /proc/sys/kernel/randomize_va_space
or
setarch $(uname -m) -R /path/to/exe
You can also confirm that your program will run under GDB if you enable ASLR:
gdb /path/to/exe
(gdb) set disable-randomization off
(gdb) run
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
Alright, this makes a lot more sense. I actually have to acquire an address range according to some other constraints too. So I am trying not to usemmap(NULL, ...). The address range I had used satisfied the other constraint. I thought this would be free for most processes too. Didn't realize with ASRL turned off, the mapping starts right from the bottom.
– Ajay Brahmakshatriya
Nov 25 '18 at 19:34
add a comment |
Does gdb use this address range in the running process?
No.
Have I cleared out some of gdb's state?
No.
Is this address range documented somewhere?
Possibly in kernel sources.
Your program makes invalid assumptions about available address space, and "blows itself up" when run with ASLR turned off (which GDB does by default).
You can confirm this by running your program outside GDB, but with ASLR disabled. It should also crash. Try one of these:
# echo 0 > /proc/sys/kernel/randomize_va_space
or
setarch $(uname -m) -R /path/to/exe
You can also confirm that your program will run under GDB if you enable ASLR:
gdb /path/to/exe
(gdb) set disable-randomization off
(gdb) run
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
Alright, this makes a lot more sense. I actually have to acquire an address range according to some other constraints too. So I am trying not to usemmap(NULL, ...). The address range I had used satisfied the other constraint. I thought this would be free for most processes too. Didn't realize with ASRL turned off, the mapping starts right from the bottom.
– Ajay Brahmakshatriya
Nov 25 '18 at 19:34
add a comment |
Does gdb use this address range in the running process?
No.
Have I cleared out some of gdb's state?
No.
Is this address range documented somewhere?
Possibly in kernel sources.
Your program makes invalid assumptions about available address space, and "blows itself up" when run with ASLR turned off (which GDB does by default).
You can confirm this by running your program outside GDB, but with ASLR disabled. It should also crash. Try one of these:
# echo 0 > /proc/sys/kernel/randomize_va_space
or
setarch $(uname -m) -R /path/to/exe
You can also confirm that your program will run under GDB if you enable ASLR:
gdb /path/to/exe
(gdb) set disable-randomization off
(gdb) run
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
Does gdb use this address range in the running process?
No.
Have I cleared out some of gdb's state?
No.
Is this address range documented somewhere?
Possibly in kernel sources.
Your program makes invalid assumptions about available address space, and "blows itself up" when run with ASLR turned off (which GDB does by default).
You can confirm this by running your program outside GDB, but with ASLR disabled. It should also crash. Try one of these:
# echo 0 > /proc/sys/kernel/randomize_va_space
or
setarch $(uname -m) -R /path/to/exe
You can also confirm that your program will run under GDB if you enable ASLR:
gdb /path/to/exe
(gdb) set disable-randomization off
(gdb) run
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
answered Nov 25 '18 at 16:10
Employed RussianEmployed Russian
126k20169239
126k20169239
Alright, this makes a lot more sense. I actually have to acquire an address range according to some other constraints too. So I am trying not to usemmap(NULL, ...). The address range I had used satisfied the other constraint. I thought this would be free for most processes too. Didn't realize with ASRL turned off, the mapping starts right from the bottom.
– Ajay Brahmakshatriya
Nov 25 '18 at 19:34
add a comment |
Alright, this makes a lot more sense. I actually have to acquire an address range according to some other constraints too. So I am trying not to usemmap(NULL, ...). The address range I had used satisfied the other constraint. I thought this would be free for most processes too. Didn't realize with ASRL turned off, the mapping starts right from the bottom.
– Ajay Brahmakshatriya
Nov 25 '18 at 19:34
Alright, this makes a lot more sense. I actually have to acquire an address range according to some other constraints too. So I am trying not to use
mmap(NULL, ...). The address range I had used satisfied the other constraint. I thought this would be free for most processes too. Didn't realize with ASRL turned off, the mapping starts right from the bottom.– Ajay Brahmakshatriya
Nov 25 '18 at 19:34
Alright, this makes a lot more sense. I actually have to acquire an address range according to some other constraints too. So I am trying not to use
mmap(NULL, ...). The address range I had used satisfied the other constraint. I thought this would be free for most processes too. Didn't realize with ASRL turned off, the mapping starts right from the bottom.– Ajay Brahmakshatriya
Nov 25 '18 at 19:34
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53465930%2faddress-ranges-reserved-by-gdb%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Check this answer: stackoverflow.com/questions/3640095/…. It looks like you need to create function within your program that gives GDB access to those memory regions if you want to inspect them.
– Paul
Nov 25 '18 at 8:48
@Paul I don't think that question is exactly related. I am not mmap'ing the memory in the kernel space. It is inside the user space -
TASK_SIZE - PAGE_SIZE. This memory should be accessible by gdb if it needs to.– Ajay Brahmakshatriya
Nov 25 '18 at 8:52
Ah, good point. Can you include the call you are making to
mmap? Are you getting an address back from mmap, or you are requesting one?– Paul
Nov 25 '18 at 8:57
@Paul I am using
MAP_FIXED-- I am passing my own address. Will add the call to mmap.– Ajay Brahmakshatriya
Nov 25 '18 at 9:11
Does it work if you remove the MAP_FIXED argument? It would be good to know if using GDB with that address space is the cause rather than a GDB issue in general.
– Paul
Nov 25 '18 at 9:29