24

This is an interview question I found in a website, the questions says: "In virtual memory, can two different processes have the same address? When you answer "No" which is correct, how one process can access another process' memory, for example the debugger can access the variables and change them while debugging?"

What I understand is :

  1. 2 diff process can have same virtual memory address. This is because each process has its own page table. Each process thinks it as 4Gb memory on a 32-bit machine. So both P1 and P2 can access address 0xabcdef - but the physical memory location might be different. Isnt this right ?

  2. The debugger works on the same principle - 2 processes can access the same address. So it can modify variables etc on the fly.

Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
Vin
  • 717
  • 1
  • 12
  • 26

5 Answers5

39

Theoretically every process executed by user in any present popular OSes(Win,linux,unix,Sol etc) are initially allowed to use the address range of 4gig ( 0x00000000 t0 0xffffffff on 32 bit platform),whether its a simple hello world program or its complex web container hosting stackoverflow site.It means every process has its range starting from the same start address and ending with the same address space VIRTUALLY. So obviously every process has that same virtual addresses in their respective virtual address space range. So answer for your first question is YES.

Difference comes when OS execute any process, modern OSes are multitasking OS and they run more than one process at any point of time.So accommodating 4gig of every process in the main memory is not feasible at all. So OSes using paging system,in which they divide the virtual address range (0x00000000 to 0xffffffff) into a page of 4k size(not always). So before starting the process it actually load the required pages which needed at the initial time to the main memory and then load the another virtual page ranges as required. So loading of virtual memory to physical memory (main memory) is called memory mapping. In this process you map the page's virtual address range to physical address range( like ox00000000 to ox00001000 virtaul address range to 0x00300000 to 0x00301000 physical address range)based on the slot free in the main memory.So at any point of time only one virtual address range will be mapped to that particular physical address range,so answer for your second question is NO.

BUT

Shared Memory concept is an exception where all the process can share some of their virtual address range with each other,that will be mapped to a common physical address space.So in this case answer can be YES.

As an example on Linux every executable require libc.so library to execute the program executable.Every process load their required libraries and allocate them some virtual address page ranges in their address space. So now consider a scenario where you are executing 100's of process where each process require this library libc.so. So if OS allocate virtual address space in every process for this library libc.so,then you can imagine the level of duplication for library libc.so & its highly possible that at any point of time you will get multiple instance of libc.so address range pages in the main memory.So to make is redundant OS will load libc.so to specific virtual address space range of every process which is mapped to a fixed physical address range in main memory.So every process will refer to that fixed physical address range to execute any code in libc.so. So in this case every process share some physical address ranges as well.

But there is no chance of two process has same physical address at the same time in the user malloced virtual address range mapping.

Hope it helps.

vaibhavatul47
  • 2,766
  • 4
  • 29
  • 42
Anil Vishnoi
  • 1,352
  • 3
  • 18
  • 25
  • ,it means that the size of virtual address space of any process is 4gbyte[32 bit environment] irrespective of how much space does it need. Am i right? How the virtual address space range is calculated? – Green goblin Jun 19 '12 at 13:57
  • 4gbytes,yes. virtual address space ranges from 0x00000000 (0) to 0xffffffff(4gbytes).Did i answered your question? – Anil Vishnoi Jun 19 '12 at 20:24
  • yeah sure.. But there is one more doubt.. i have heard that whenever scheduler selects any process for execution, its pages must first be loaded into memory. So, my question is: Does at a time, only one process page table exists? – Green goblin Jun 20 '12 at 07:01
12

1)

  • Same physical memory address at the same time: NO
  • Same virtual memory address at the same time: YES (each one maps to differnet physical address, or swap space)

2) I think the debuggers don't access directly the other process debugged but communicates with the runtime in the debugged process to do that changes.

That said, maybe the OS or processor instructions provide access/modify to other's memory access if you have the right. That doesn't mean it has the SAME address, it only says process 1 can say "access memory @address1 in Process2". Someone (processor / OS / runtime) will do that for process 1.

helios
  • 13,574
  • 2
  • 45
  • 55
  • 7
    Two processes can have portions of their virtual address space point to the same physical memory at times (not _all_ the time, of course). This happens with eg shared memory or libraries. – bdonlan Aug 03 '11 at 16:05
  • 2
    Do the two processes think that they have the entire 4 GB memory available to them? – Dubby Jun 06 '14 at 07:47
  • Dubby: yes. Every process must get memory anyway (malloc in C, new in C++/Java, etc) and the OS will catch any non valid address access and raise an error. What they process really have is a 4GB memory __address space__ available. Sample: OS will reserve a piece of memory for a process. The process accesses it at position 5 (to say something) but it can be in physical position 100. Every access to memory is guarded by the OS and it will throw an error in case it's not valid. – helios Jun 11 '14 at 14:57
3

Yes, it's definitely possible for the same address to map to different physical memory depending on the process that's referencing it. This is in fact the case under Windows.

Steven Sudit
  • 19,391
  • 1
  • 51
  • 53
1

Sometimes I feel like the "elder" in the Minolta commercial... In the 1960's Multics was created using Virtual Memory. The last Multics system was shut down October 30, 2000 at 17:08Z.

In Multics, only one copy of any program was present in memory, regardless of how many users were running it. So that means that each user process had both the same physical and virtual address for the program.

When I look at the Windows Task Manager and see multiple copies of a program (e.g. svchost.exe) I wonder why / how the revolutionary concepts in Multics were lost.

dbasnett
  • 11,334
  • 2
  • 25
  • 33
  • 1
    @dbasnett: that's a question of terminology, isn't it? Each user would need its own stack, instruction pointer, heap even if "only one program" would be running, wouldn't he? And those are encapsulated in a process in Windows (and Linux and ...). Static pages (executable code loaded from binaries for example) is indeed shared by current OS as well. Or am I missing something big here? – Joachim Sauer Aug 24 '10 at 11:12
  • @Joachim Sauer: so maybe the answer (after all) is yes, the can have the same address! :) Anyway, I think, the question is ambiguous. – helios Aug 24 '10 at 11:15
  • 1
    All executable code in Multics was static, and yes each user/process had storage for user specific data. I can look through windows task manager and see many cases where the image name is the same, which I take to mean that there are multiple copies of the same code running. I have NOT been an OS expert for some time, so I might not understand completely what I am seeing. – dbasnett Aug 24 '10 at 12:13
  • Emacs was a very popular editor in Multics. If 100 people were using Emacs on the same machine, there would only be one copy running. Let me re-state one thing, ALL executable code in Multics was static. Link to Multics http://www.multicians.org/ – dbasnett Aug 24 '10 at 12:16
  • Actually, when multiple copies of the same executable are running on Windows, the unmodified pages of memory are shared. – Steven Sudit Aug 24 '10 at 12:19
  • 1
    Multics did not allow any executable to modify itself. – dbasnett Aug 24 '10 at 13:04
  • Well, with Windows, if an executable modifies a (4k) page that would otherwise be mapped to the EXE/DLL, there's a copy-on-write invoked by the OS, and that page then becomes backed by the swap file. Best of both worlds, really. – Steven Sudit Aug 24 '10 at 21:05
  • @Steven - The history of self-modifying code is not good, IMHO. In Multics there were three bits related to accessing segments (i.e. files containing data or code to be executed) that was enforced in hardware. Those bits were read, execute, and write. Code segments had read / execute permissions typically and data had read and / or write, but never execute. It should be apparent that an environment like that would not be virus friendly. In 198x Multics received one of the highest DOD security ratings possible. – dbasnett Aug 24 '10 at 23:19
  • It's not self-modifying code. I'm talking about a data segment whose initial values are changed after loading. This triggers a copy-on-write, but only for that page. All unmodified pages of a DLL are shared across EXE's. – Steven Sudit Aug 24 '10 at 23:52
  • Then I was confused about "...if an executable modifies a (4k) page that would otherwise be mapped to the EXE/DLL...". Sorry. – dbasnett Aug 25 '10 at 11:24
  • My fault for not being clear. Normally, any given page is flagged as either data or code, where only the former can be modified (and only the latter can be executed). This sanity check also helps against stack overflow exploits. – Steven Sudit Aug 25 '10 at 13:55
  • As I have stated I am not a Windows / Linux / etc. OS guru. My question is; Is the flag enforced in hardware? I will also tell you that Multics had many other security mechanisms. There are those of us that believe that if Honeywell had given Multics the resources it needed, Honeywell might have have given IBM a run for its money. – dbasnett Aug 26 '10 at 00:01
  • Comparaison Multics ↔ Windows: a big difference coming from the epoch (pun intended :-). At the time Multics was designed, people **had** to be competent, they could not afford to waste any byte, while challenging complex challenges. Multics implemented revolutionary concepts, not only technically but also ergonomically, a lot of which cannot be found in more modern systems, unfortunately. – Déjà vu Oct 21 '15 at 10:55
  • Soooo many mistakes about Multics in these comments! Multics code was all "pure", and also fully dynamically linked. In Multics many copies of a program can be running at a time (e.g. one copy for every user), but they all share the same in-memory segment(s) of the code (thus the need for it to be "pure" code), and each process will have its own stack and data segments. In Multics many programs can also access the same file at the same time, and they do so via a memory segment, and they may all share the same memory segment at once so there's only one copy of the file in memory at once. – Greg A. Woods Nov 03 '15 at 21:31
  • @GregA.Woods - The point of having programs that did not modify themselves was to eliminate copies of the same program being ran. – dbasnett Nov 03 '15 at 23:26
  • I think you're confusing the concepts of copies of code in memory and instances of execution. Multics made it easy (though not 100% mandatory) for a single copy of a procedure (or set of procedures) to be shared amongst all processes, thus allowing many processes to run the same program at the same time but all sharing the same code segment. Indeed since Multics was SMP, many processors could execute many processes, all running the same program at the same time using just one copy of the code in one shared segment. – Greg A. Woods Nov 05 '15 at 03:58
  • @GregA.Woods - I think I was a Multician. I was simply correcting your "one copy for every user" statement. – dbasnett Nov 05 '15 at 12:27
  • Terminology: things that "run" are processes. You can have many processes running, usually one per user on Multics. Thus many "copies", or "instances" of a program running at once in the system, one per user, if they all decide to run the same program at the same time. However: to quote above "they all share the same in-memory segment(s) of the code". Don't pick phrases out of context! Also, don't forget about the binder -- it can in effect force multiple copies of code text. – Greg A. Woods Nov 05 '15 at 18:49
  • @GregA.Woods - I found this, "Soooo many mistakes about Multics in these comments! Multics code was all "pure", and also fully dynamically linked. In Multics many copies of a program can be running at a time (e.g. one copy for every user), but they all share the same in-memory segment(s) of the code (thus the need for it to be "pure" code), ..." to be confusing. Being a Multician I understood your segments comment, and your point, but a non-Multician may not. But what do I know, I only worked at Honeywell... – dbasnett Nov 06 '15 at 00:54
  • The problem is you kept saying "only one copy of any program was running". That's not true. You're going too far in your claim. Everyone gets their own process and more than one process may run the same program at the same time (so the same program can run many times at once), but only the code segment is shared between those processes. Each process has its own data and stack segments though. More or less _exactly_ the same thing happens in any modern Unix (including Mach-Unix hybrids like OS X) or Linux or even Windows (or OS/2) as well. – Greg A. Woods Nov 06 '15 at 06:52
  • I edited my original response. Today's users equate, for the most part, machine = user = program(s). – dbasnett Nov 06 '15 at 11:22
1

Each process has a address space of 4GB in a 32 bit system. Where is this real 4GB is managed by the OS. So in principle 2 different process can have same addresses that is local to the process.

Now when one process has to read the memory of another process it has to either communicate with the other process (memory mapped files etc.,) or use the Debug apis like OpenProcess/ReadProcessMemory.

What I am sure is one process cannot directly go and read the virtual memory of other process atleast in Win32 without the help of the OS.

ferosekhanj
  • 1,086
  • 6
  • 11