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).

edited Nov 25 '18 at 9:15

asked Nov 25 '18 at 8:44

Ajay 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 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

|
show 2 more comments

I have a program that mmaps memory at higher addresses using MAP_FIXED at TASK_SIZE - PAGE_SIZE.

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;

}

edited Nov 25 '18 at 9:15

asked Nov 25 '18 at 8:44

Ajay 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 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

|
show 2 more comments

I have a program that mmaps memory at higher addresses using MAP_FIXED at TASK_SIZE - PAGE_SIZE.

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;

}

edited Nov 25 '18 at 9:15

asked Nov 25 '18 at 8:44

Ajay Brahmakshatriya

6,96531636

I have a program that mmaps memory at higher addresses using MAP_FIXED at TASK_SIZE - PAGE_SIZE.

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;

}

c linux gdb

edited Nov 25 '18 at 9:15

asked Nov 25 '18 at 8:44

Ajay Brahmakshatriya

6,96531636

edited Nov 25 '18 at 9:15

asked Nov 25 '18 at 8:44

Ajay Brahmakshatriya

6,96531636

edited Nov 25 '18 at 9:15

asked Nov 25 '18 at 8:44

Ajay Brahmakshatriya

6,96531636

asked Nov 25 '18 at 8:44

Ajay Brahmakshatriya

6,96531636

asked Nov 25 '18 at 8:44

Ajay 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 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

|
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 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

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

|
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

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 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 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 |

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
});

}
});

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

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

Name

Required, but never shown

1 Answer
1

active

oldest

votes

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

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 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 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 |

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

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 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 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 |

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

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 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

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 Russian

126k20169239

answered Nov 25 '18 at 16:10

Employed Russian

126k20169239

answered Nov 25 '18 at 16:10

Employed Russian

126k20169239

answered Nov 25 '18 at 16:10

Employed 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 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 |

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 |

draft saved

draft discarded

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.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Post as a guest

Name

Required, but never shown

Name

Required, but never shown

Name

Required, but never shown

This page is only for reference, If you need detailed information, please check here

搜尋此網誌

Nsryjdtyk