Back to General and Gameplay Programming

Access Violations and Memory

General and Gameplay Programming Programming

Started by ordered_disorder November 11, 2005 03:53 PM

25 comments, last by SiCrane 18 years, 5 months ago

2,466

November 12, 2005 02:35 AM

Quote:Original post by ordered_disorder
I guess I have to go through the operating system to get access to my program's memory, i.e. by using functions defined in kernal32.lib

Bingo!
The OS allocates memory, not your program. The memory address space is shared amoungst all processes, and the OS will give you bits that you can use, because it is the only thing keeping track of who is using what bit of memory.

"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

LessBread

1,415

November 12, 2005 03:11 AM

The physical memory is spread out among all processes, but each process has it's own virtual address space.

"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man

iMalc

2,466

November 12, 2005 12:27 PM

Quote:Original post by LessBread
The physical memory is spread out among all processes, but each process has it's own virtual address space.

Okay, so you mean that two processes can be allocated the same virtual memory addresses when calling new, and yet the physical memory accessed by both will be different between them.
Sorry, I thought that because it's best to rebase your DLLs to avoid automatic relocation, that it was bigger than that.
I really should learn how shared memory works too.

Still, you can't go picking random memory addresses to write to, and expect to not get access violations anyway. Nor can one expect that even half of the 4GB address range of a process is all actually mapped to physical memory. There's obviously got to be large hole(s) somewhere, especially around 0!

"In order to understand recursion, you must first understand recursion."
My website dedicated to sorting algorithms

SiCrane

11,840

November 12, 2005 12:34 PM

Access violations are only peripherally related to what physical memory is associated with what address, what matters is if the virtual memory is committed. If the virtual memory is committed when a read or write occurs to that address no access violation will be registered even if there is no physical memory mapped to that address.

And no physical memory will ever be mapped to the range 0x0000 0000 to 0x0000 ffff because that is a reserved area meant to catch bad pointer access.

Rebasing DLLs just prevents the loader from doing extra work if two DLLs happen to have the same base address, it's not really related to this discussion.

LessBread

1,415

November 12, 2005 05:32 PM

Quote:Original post by iMalc
Okay, so you mean that two processes can be allocated the same virtual memory addresses when calling new, and yet the physical memory accessed by both will be different between them.

That's what happens.

Quote:Original post by iMalc
Sorry, I thought that because it's best to rebase your DLLs to avoid automatic relocation, that it was bigger than that.

The advantage gained by dll rebasing pertains to avoiding load clashes between different dlls. This happens within the address space of a single process.

Quote:Original post by iMalc
I really should learn how shared memory works too.

You probably should learn about how virtual memory works on Windows first. This article, The Virtual-Memory Manager in Windows NT, might be old but the basics it lays down are still used today in XP, but don't get too bogged down in the details because you don't need to know how an engine works in order to drive a car.

Quote:Original post by iMalc
Still, you can't go picking random memory addresses to write to, and expect to not get access violations anyway. Nor can one expect that even half of the 4GB address range of a process is all actually mapped to physical memory. There's obviously got to be large hole(s) somewhere, especially around 0!

Yes, you can't just go picking randmon addresses and expect them to be valid. After reading the above link, you'll have a better idea of how virtual memory is organized and how it relates back to physical memory. For what it's worth, there are large "holes" in the virtual address space of a process. There's a huge one between 0x10000000 and 0x60000000 and addresses above 0x80000000 are off limits to user mode programs alltogether.

"I thought what I'd do was, I'd pretend I was one of those deaf-mutes." - the Laughing Man

SiCrane

11,840

November 12, 2005 05:36 PM

Quote:Original post by LessBread
Yes, you can't just go picking randmon addresses and expect them to be valid. After reading the above link, you'll have a better idea of how virtual memory is organized and how it relates back to physical memory. For what it's worth, there are large "holes" in the virtual address space of a process. There's a huge one between 0x10000000 and 0x60000000 and addresses above 0x80000000 are off limits to user mode programs alltogether.

0x1000 0000 to 0x6000 0000 isn't off limits to the application. Seeing as 0x1000 0000 is the default loading address for DLLs linked with MSVC's linker, that area being off limits wouldn't make much sense.

dbzprogrammer

100

November 12, 2005 05:47 PM

unsigned int* ptr_to_mem = (unsigned int*) 0x00000000;*ptr_to_mem = 0xFFFFFFFF;

Shouldn't you NOT have the dereference operator in the second line?

I think your getting an access violation because your trying to set the value (i.e. 5, not the memory adress) to 0xFFFFFFFF

We should do this the Microsoft way: "WAHOOOO!!! IT COMPILES! SHIP IT!"

rip-off

11,000

November 12, 2005 05:54 PM

Quote:Original post by dbzprogrammer
unsigned int* ptr_to_mem = (unsigned int*) 0x00000000;*ptr_to_mem = 0xFFFFFFFF;
Shouldn't you NOT have the dereference operator in the second line?

either pointer is wrong. they are both arbitrary and dereferencing them will lead to a segfault (at best). if it isnt dereferenced then its pointless. if it is then storage should be allocated properly

blog | twitter

dbzprogrammer

100

November 12, 2005 06:02 PM

void main(){	unsigned int *ptr_to_mem = (unsigned int *)0x00000000; // could be anything for all I care, 0xXXXXXXXX	ptr_to_mem = (unsigned int *)0xFFFFFFFF;}

This works like a charm...

We should do this the Microsoft way: "WAHOOOO!!! IT COMPILES! SHIP IT!"

dbzprogrammer

100

November 12, 2005 06:03 PM

Quote:Original post by rip-off
Quote:Original post by dbzprogrammer
unsigned int* ptr_to_mem = (unsigned int*) 0x00000000;*ptr_to_mem = 0xFFFFFFFF;
Shouldn't you NOT have the dereference operator in the second line?
either pointer is wrong. they are both arbitrary and dereferencing them will lead to a segfault (at best). if it isnt dereferenced then its pointless. if it is then storage should be allocated properly

Then why is it compiling? God I'm so lost... Here's what I got. he's making a unsigned int pointer to some point in memory, and then is trying to change it to something else... Very interesting though!

We should do this the Microsoft way: "WAHOOOO!!! IT COMPILES! SHIP IT!"

Access Violations and Memory

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Access Violations and Memory

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines