<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&amp;feed=atom&amp;title=Operating_Systems_2026F_Lecture_5</id>
	<title>Operating Systems 2026F Lecture 5 - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&amp;feed=atom&amp;title=Operating_Systems_2026F_Lecture_5"/>
	<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2026F_Lecture_5&amp;action=history"/>
	<updated>2026-10-05T10:57:18Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.42.1</generator>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2026F_Lecture_5&amp;diff=25156&amp;oldid=prev</id>
		<title>Soma: Created page with &quot;==Video==  Video from the lectures given on September 24th and 25th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05a-20260924.mp4 Lecture 5A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05b-20260925.mp4 Lecture 5B]  ==Notes==  ===Lecture 5A===  &lt;pre&gt; Lecture 5a ----------  The memory map of a process  - every process has its own view of memory, cannot see the memory of other...&quot;</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=Operating_Systems_2026F_Lecture_5&amp;diff=25156&amp;oldid=prev"/>
		<updated>2026-09-25T21:10:27Z</updated>

		<summary type="html">&lt;p&gt;Created page with &amp;quot;==Video==  Video from the lectures given on September 24th and 25th, 2026 are now available: * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05a-20260924.mp4 Lecture 5A] * [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05b-20260925.mp4 Lecture 5B]  ==Notes==  ===Lecture 5A===  &amp;lt;pre&amp;gt; Lecture 5a ----------  The memory map of a process  - every process has its own view of memory, cannot see the memory of other...&amp;quot;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;==Video==&lt;br /&gt;
&lt;br /&gt;
Video from the lectures given on September 24th and 25th, 2026 are now available:&lt;br /&gt;
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05a-20260924.mp4 Lecture 5A]&lt;br /&gt;
* [https://homeostasis.scs.carleton.ca/~soma/os-2026f/lectures/comp3000-2026f-lec05b-20260925.mp4 Lecture 5B]&lt;br /&gt;
&lt;br /&gt;
==Notes==&lt;br /&gt;
&lt;br /&gt;
===Lecture 5A===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Lecture 5a&lt;br /&gt;
----------&lt;br /&gt;
&lt;br /&gt;
The memory map of a process&lt;br /&gt;
 - every process has its own view of memory, cannot see the memory of other processes&lt;br /&gt;
 - what goes in that address space?&lt;br /&gt;
&lt;br /&gt;
Note that, almost always, the entire address space is NOT VALID MEMORY&lt;br /&gt;
 - if you access most of it, you&amp;#039;ll get an error (segmentation error generally)&lt;br /&gt;
&lt;br /&gt;
So what is a segment?&lt;br /&gt;
&lt;br /&gt;
Well first, consider the address&lt;br /&gt;
 - 64 bit pointer, so 2^64 possible addresses&lt;br /&gt;
&lt;br /&gt;
We can&amp;#039;t have this much RAM, so most of these addresses are invalid.&lt;br /&gt;
 - but which ones are valid?&lt;br /&gt;
 - and on what basis?&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
First, we should talk about the stack and the heap&lt;br /&gt;
&lt;br /&gt;
The heap is just memory that is allocated in chunks, with each chunk pointed to&lt;br /&gt;
by a pointer&lt;br /&gt;
 - when you call malloc, you&amp;#039;re getting memory from the heap&lt;br /&gt;
 - when you create a new object in most languages other than C, you&amp;#039;re really&lt;br /&gt;
   getting memory from the heap (mostly)&lt;br /&gt;
&lt;br /&gt;
How to manage the heap is a complex problem, solved by memory allocators, garbage collection, etc (beyond the scope of this class)&lt;br /&gt;
&lt;br /&gt;
The stack is memory that is managed in a very simple way: as a stack&lt;br /&gt;
 - LIFO (last in, first out), e.g., a stack of plates&lt;br /&gt;
&lt;br /&gt;
A stack is great because...&lt;br /&gt;
 - no memory leaks!&lt;br /&gt;
 - allocation and de-allocation is trivial&lt;br /&gt;
&lt;br /&gt;
But the discipline of a stack only makes sense in certain contexts&lt;br /&gt;
&lt;br /&gt;
Fortunately, we&amp;#039;ve built our programming languages around those contexts:&lt;br /&gt;
 FUNCTIONS&lt;br /&gt;
&lt;br /&gt;
When a program enters a function, it allocates memory for the function&lt;br /&gt;
When the function exits, that function&amp;#039;s storage needs to be de-allocated&lt;br /&gt;
&lt;br /&gt;
So we need somewhere to put the stack and somewhere to put the heap&lt;br /&gt;
 - could separate, but normally are allocated together&lt;br /&gt;
&lt;br /&gt;
Stack grows from himem (of data segment) down&lt;br /&gt;
heap grows up from the bottom of the data segment&lt;br /&gt;
&lt;br /&gt;
if you put some invalid memory in the middle, you can know when they would potentially overlap (because access to it will generate an error)&lt;br /&gt;
&lt;br /&gt;
a segmentation violation is just an access to memory that hasn&amp;#039;t been allocated&lt;br /&gt;
&lt;br /&gt;
So what&amp;#039;s in memory?&lt;br /&gt;
&lt;br /&gt;
&amp;lt;top&amp;gt;&lt;br /&gt;
  command line args, environment vars&lt;br /&gt;
&lt;br /&gt;
  Data&lt;br /&gt;
 ------ &amp;quot;break&amp;quot;&lt;br /&gt;
  Code&lt;br /&gt;
&lt;br /&gt;
&amp;lt;bottom&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
So the command line arguments and environment variables passed to a program&lt;br /&gt;
are at the top of the process&amp;#039;s address space. The kernel put them there when&lt;br /&gt;
the program was launched.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
fork duplicates the current process&lt;br /&gt;
execve replaces the current program with a new one&lt;br /&gt;
 - neither act like normal &amp;quot;functions&amp;quot;, because they are system calls&lt;br /&gt;
&lt;br /&gt;
Windows has &lt;br /&gt;
&lt;br /&gt;
Remember in C we make system calls by calling functions&lt;br /&gt;
 - the functions that make system calls are using compiler-specific ways&lt;br /&gt;
   of making the special CPU instructions for system calls&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
fork &amp;lt;- to make a process&lt;br /&gt;
execve &amp;lt;- to load a program into a process&lt;br /&gt;
exit &amp;lt;- to terminate a process&lt;br /&gt;
wait &amp;lt;- wait for a child to finish&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
If the parent doesn&amp;#039;t wait for its child, and the child terminates,&lt;br /&gt;
the child sticks around in a zombie state&lt;br /&gt;
 - it is already dead but still around, cannot be further killed&lt;br /&gt;
&lt;br /&gt;
zombies stick around as long as their parent exists&lt;br /&gt;
zombies are &amp;quot;reaped&amp;quot; once the parent dies&lt;br /&gt;
 - init or similar will call wait&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
How do we run programs?&lt;br /&gt;
&lt;br /&gt;
Run fork&lt;br /&gt;
 - duplicates current process, creating a child process&lt;br /&gt;
&lt;br /&gt;
in the parent&lt;br /&gt;
 - wait for the child to finish, or&lt;br /&gt;
 - go do other work and call wait will notified&lt;br /&gt;
   of child termination&lt;br /&gt;
&lt;br /&gt;
in the child&lt;br /&gt;
 - set up things for new program&lt;br /&gt;
   - standard in, out, error, other open files&lt;br /&gt;
     - close any files that SHOULD NOT be accessible&lt;br /&gt;
   - command line arguments&lt;br /&gt;
   - environment variables&lt;br /&gt;
 - execve new program&lt;br /&gt;
&lt;br /&gt;
In practice, you won&amp;#039;t actually see the fork system call nowadays,&lt;br /&gt;
at least on Linux systems. Instead, you&amp;#039;ll see clone&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Containers - have you heard of them?&lt;br /&gt;
&lt;br /&gt;
So containers are all about managing software and dependencies&lt;br /&gt;
 - very poor security isolation properties&lt;br /&gt;
&lt;br /&gt;
Turns out when you create a new process, you can change its view of the world&lt;br /&gt;
 - e.g., give it a different view of the filesystem&lt;br /&gt;
&lt;br /&gt;
namespaces is how you map the following for a process and its children&lt;br /&gt;
&lt;br /&gt;
 /newsystem/bin =&amp;gt; /bin&lt;br /&gt;
 uid 1000 =&amp;gt; uid 0&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
===Lecture 5B===&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
Lecture 5b&lt;br /&gt;
----------&lt;br /&gt;
&lt;br /&gt;
Planning to move midterm to Oct 20, 21&lt;br /&gt;
 - so review will be Oct 15, 16&lt;br /&gt;
 - assignment 2 will be due on the 15th 2:30 PM&lt;br /&gt;
 - a1 will be put off a bit will finalize when posted (you&amp;#039;ll have at least a week)&lt;br /&gt;
 - A1 will be based on T1 and T2&lt;br /&gt;
&lt;br /&gt;
For today, we&amp;#039;re talking memory&lt;br /&gt;
&lt;br /&gt;
With modern OSs, each running process gets its own address space&lt;br /&gt;
 - so 64 bits in size&lt;br /&gt;
 - most of that address space is not allocated, so cannot&lt;br /&gt;
   be used or will generate an error&lt;br /&gt;
 - typically the error is a &amp;quot;segmentation violation&amp;quot;&lt;br /&gt;
   - so what is a segment?&lt;br /&gt;
&lt;br /&gt;
A segment is a unit of memory that has a specific &amp;quot;purpose&amp;quot;&lt;br /&gt;
 - contiguous addresses&lt;br /&gt;
&lt;br /&gt;
What segments are there? You&amp;#039;ll at least have&lt;br /&gt;
 - code (text), read only&lt;br /&gt;
 - data, read write&lt;br /&gt;
   - global variables&lt;br /&gt;
   - dynamically-allocated storage&lt;br /&gt;
&lt;br /&gt;
The data segment has to store two logically distinct types of dynamically allocated memory: the stack and the heap&lt;br /&gt;
&lt;br /&gt;
The heap is used to store dynamically allocated objects/data structures that have indeterminate lifetimes&lt;br /&gt;
 - could be around for a few milliseconds&lt;br /&gt;
 - could exist for most of the run of the program (but aren&amp;#039;t known at compile time)&lt;br /&gt;
 - malloc (C), new (C++), most everything in JavaScript &amp;amp; Python&lt;br /&gt;
&lt;br /&gt;
Now this might sound complicated because IT IS&lt;br /&gt;
 - entire area of memory management techniques&lt;br /&gt;
 - automatic memory management is called &amp;quot;garbage collection&amp;quot;&lt;br /&gt;
   - not only but most general approach&lt;br /&gt;
&lt;br /&gt;
The heap is complex, hard to do right, so traditionally UNIX programs have avoided using the heap as much as possible and instead used the stack&lt;br /&gt;
&lt;br /&gt;
So what&amp;#039;s the stack?&lt;br /&gt;
 - data structure that respects LIFO discipline (last in, first out)&lt;br /&gt;
&lt;br /&gt;
A process normally has one stack that is used for functions&lt;br /&gt;
 - local variables&lt;br /&gt;
 - arguments&lt;br /&gt;
 - return values&lt;br /&gt;
&lt;br /&gt;
heap grows up from bottom of data segment&lt;br /&gt;
stack grows down from the top of the data segment&lt;br /&gt;
&lt;br /&gt;
normally some invalid memory in the middle so you know when the two run into each other&lt;br /&gt;
&lt;br /&gt;
Where do the environment variables and command line variables come from?&lt;br /&gt;
&lt;br /&gt;
Those are both arguments of the execve system call&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
Key system calls for running a program in a new process are:&lt;br /&gt;
 - fork&lt;br /&gt;
 - execve&lt;br /&gt;
 - wait&lt;br /&gt;
&lt;br /&gt;
fork: duplicates the current process&lt;br /&gt;
 - new process is called the child, old the parent&lt;br /&gt;
 - except for the PID/PPID and the return value of fork(),&lt;br /&gt;
   code, data, and other state are IDENTICAL&lt;br /&gt;
&lt;br /&gt;
child calls execve&lt;br /&gt;
 - sets up argv, env, open files (standard in/out/error +),&lt;br /&gt;
   signal handlers (will discuss later)&lt;br /&gt;
 - then loads new program binary with execve call, which REPLACES&lt;br /&gt;
   the code in the process&lt;br /&gt;
 - if execve returns, it failed&lt;br /&gt;
&lt;br /&gt;
parent calls wait&lt;br /&gt;
 - either literally waiting for child process to terminate, or&lt;br /&gt;
 - in response to a signal that the child has terminated&lt;br /&gt;
&lt;br /&gt;
Why does the parent care about the child process terminating?&lt;br /&gt;
 - because it has a return status&lt;br /&gt;
&lt;br /&gt;
processes terminate with the exit system call, and exit takes an integer argument that is past via wait to the parent&lt;br /&gt;
&lt;br /&gt;
Modern Linux systems tend not to use the fork system call&lt;br /&gt;
 - fork() actually calls clone&lt;br /&gt;
&lt;br /&gt;
If you don&amp;#039;t use setarch -R to run 3000memview, addresses will be randomized. This is ASLR in action: address space layout randomization&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;/div&gt;</summary>
		<author><name>Soma</name></author>
	</entry>
</feed>