Segmentation fault while reading Memory in C++

Question

I am just trying to get Value stored at a specific memory address using two C++ codes

Code which I using to write data to memory and get its address :

#include <iostream>

using namespace std;

int main()
{
  int i = 10;
  cout<<&i<<endl;
  cin>>i; // This is just to make sure program doesn`t end

  return 0;
}

I used cin>>i; just to make sure that it doesn't end. After getting the address of int i, put in the following code :

#include <iostream>

using namespace std;

int main()
{
  // This address changes everytime and I change it everytime
  // This is just one temporary address
  volatile int *x = (volatile int *)0x7ffef9246e74; // [1]
  int y = *x;
  cout<<y<<endl;

  return 0;
}

[1] : I copied this line from this page.

Program #1 keeps running while I run Program #2

On running the second code, I am getting segmentation fault (core dumped). Any help?

The value `0x7ffef9246e74` is wrong. It's not the address of an object of type `int`. — Kerrek SB, Jun 02 '15 at 17:39
The seg-fault is not caused by the code itself, but most likely by the operating system which doesn't allow you to access the given address. — Daniel Frey, Jun 02 '15 at 17:39
If you run the first program twice, do you get the same value printed out? — Mark Plotnick, Jun 02 '15 at 17:40
@MarkPlotnick That's why I used `cin>>i`. I first run the first code then second, — 0x6773, Jun 02 '15 at 17:41
Addresses only exist within *one* program, and only within one execution of said program. — Kerrek SB, Jun 02 '15 at 17:41
Could you please run the first program again, and see whether the address printed out is the same? — Mark Plotnick, Jun 02 '15 at 17:42
@MarkPlotnick it gives different address different time, but I change it everytime in second code. It just one case. — 0x6773, Jun 02 '15 at 17:44
What OS are you running under? If a non-embedded system, what makes you think it is legal to write to/read from to a hard-coded address that the OS has not provided you? Of course it is going to prevent a read from random memory for the OS's own protection. Even Windows... — Michael Dorgan, Jun 02 '15 at 17:45
@mnciitbhu: If you know that `i`'s location will change between invocations of program #1, I don't understand what makes you think it _won't_ change between invocations of program #1 and a completely separate program #2. It looks like you're keeping program #1 _while_ running program #2, keeping `i` in memory. An inventive approach to inter-process data sharing, I suppose. :) — Lightness Races in Orbit, Jun 02 '15 at 18:01
@LightnessRacesinOrbit it think you only understood my programs! — 0x6773, Jun 02 '15 at 18:07
@mnciitbhu Even if the first program is still running, it lives in its own memory space and other programs can't access that. Just think about how easy it would be if other processes are allowed to access your memory to steal passwords, SSH-keys, etc. - the operating system will therefore do anything in its power to prevent you from doing that! — Daniel Frey, Jun 02 '15 at 18:13

Daniel Frey · Accepted Answer · 2015-06-02T17:54:48.030

Your model of how modern operating systems, compilers, etc. work is wrong. When you run the program the first time, the process gets assigned a memory space. Everything within this memory space, which is a virtual memory space, gets mapped to physical memory by the processor's MMU.

When the process finished, its memory space no longer exists. The next time you start the same program, it will run in another and independent memory space. It might be mapped to different physical memory addresses and even the virtual addresses are either not the same or they are cleared to make sure that no information is leaked from former processes.

This means that when you enter the address from the first program into the second, it has no meaning there. What is worse is that the memory address from the first run is not part of the virtual memory space of the second one when you run it, hence the CPU's MMU detects an illegal access to a memory location and you get a seg-fault.

This is true as long as he is working with an OS that manages memory. I wanted to be sure this wasn't in embedded land where you can do things like this. — Michael Dorgan, Jun 02 '15 at 17:56
@MichaelDorgan True, but the symptoms of OPs problem already gave the non-embedded land away :) — Daniel Frey, Jun 02 '15 at 17:57

Segmentation fault while reading Memory in C++

1 Answers1