Cracking interview questions about OS processes (3/3)

Cracking interview questions about OS processes (3/3)

Why are technical interviews so... difficult?

Cause the interviewers are damn good at asking questions. They'll see through you and understand what you remember vs what you've actually learnt. We've to be really thorough, at least with topics we claim to be good at!

But, how do I go deep into learning something?

Doing two things in my opinion is the key differentiation between people who just "know" something & people who can "use" what they've learnt to achieve something.

  1. Trying it out
  2. Asking questions

Let me tell you how to do that.

Virtual Memory

Virtual Memory is a foundational concept that anyone who's taken a level-1 OS class/course would know about. It would be safe to say that a high % of these folks would have resorted to lectures/books to learn about it.

Did you get to learn about virtual memory before? If so, did you get to try it out?

You might be thinking, how in the world am I gonna "try" virtual memory out? It's not like I can use a microscope to take a peek into my OS.

I'll let you in on a secret - Anything can be tried out!

Let's see how we can go about doing it. So, virtual memory basically is an additional layer of memory that OS provides processes with rather than direct access to the physical memory. OK, what's the role of the OS here? It maps virtual memory to some physical memory. This, my friend, is where the show usually stops. How do we try this out?

In the Virtual Memory Byte, you'll take a peek into the page table of processes, where you will find the memory mapping of virtual memory address to its corresponding physical memory address.

Memory mapping using program in Virtual Memory Byte
Memory mapping - Virtual Memory Byte

With being able to see the mappings, you're all set for my second ingredient to mastery - Asking questions

How do we come up with questions, when we see something like the above picture?

By being a curious šŸ±!

We can see that a virtual address (0x00400000) for a process(29066) is being mapped in the above picture. Some questions we should ask are:

  1. Does every virtual address have a corresponding physical memory mapping?
  2. Are the mappings unique? If not, when do multiple virtual addresses share the same physical address?
  3. Can the mapping for an address change during the course of the process?

Coming up with questions can be hard initially. The Virtual Memory Byte gives you questions as well. You can utilize these to dig in and use it as a framework to ask even more questions.

Questions to improve your understanding of the concept by being curious from Virtual Memory Byte
Crio Byte: Virtual Memory

After completing the Virtual Memory Byte, you will unlock the answers to the mystery of Virtual Memory vs Physical Memory. Memory addresses and memory mapping will then be, well, easy!

Not only those earlier questions, but you'll also be able to answer questions like these is a more confident way:

1. How are you able to run a video game of size larger than your computerā€™s RAM?
2. Does a particular VM address always map to a specific PM address? What about in case of a specific program?

Excited to get started? Click below to enroll!

Understanding Function Call Stacks

Familiar with this?

Example of a stack trace in Java
Stack Trace

You would be thinking, "Is that even a question?" šŸ˜…

Okay, you've done your fair share of programming and have met with the stack trace a good number of times. Have you ever thought how this is made possible?

Function call stacks are part of a process' memory which stores data related to function calls. Seems like cool stuff. How do I go about learning it?

Just like we saw how to comprehend Virtual Memory the right-way, we need to see how to try out the Function Call Stack. What do we want to try out here?

Yep! That would be - accessing a call stack and the data stored on it!

Accessing local variable of a function from another function using program in the Understanding Function Call Stacks Byte
Accessing local variable of a function from another function

The Understanding Function Call Stacks (UFCS) Byte zooms in on the internals of a process' call stack.

You'll use programs to answer these:

  1. Can two variables access the same address?
  2. Where is an initialized static variable stored in a process' memory? What if it is uninitialized?
  3. How to access local variable of a function from another function? (Of course, no parameter passing allowed šŸ˜„)
  4. How to access a function's parameter value without using the variable passed?

And like earlier, you'll be presented with more "how" questions, expanding your learning.

Seems exciting but quite an involved topic to learn. What if I get stuck and am not able to proceed further?

We have you covered via HINTS, don't worry. Hints won't kill your learning experience by handing over the answers, they'll do just enough to help you progress.

In platform hints provided
In-platform hint

You'll walk away with the know-how to:

  1. Correlate and visualize what people mean by a stack trace or call stack when they talk about debugging.
  2. Understand how the program is able to print the stack trace at run-time, when thereā€™s an issue.

Excited to get started? Click below to enroll!

Challenge

Feeling confident about function call stacks after going through the UFCS Byte? Are you up for a challenge?

We have a function first() that calls second() which in turn calls third(). Can you hijack the call stack to return control from third() to first() directly instead of via second()?
void third() {
  // I don't want to return to second() :(
}

void second () {
  third();
}

void first() {
  // blah, blah...
  second();
  // blah, blah, blah...
}

void main() {
   first();
}

Submission:

How did you address this challenge with your practical knowledge? Blog about it on Medium and share the link on LinkedIn with #criodo #learnbydoing or in the comments section below. Your blog may get recognised by us if you have dismantled the challenge successfully!

Recap

Bytes provide a framework for learning a key concept by doing. We have covered two Bytes here - Out Of Memory and Fun with Process Internals - that have enhanced your knowledge across Process Internals and OS Internals.

Did you go through the Bytes? If not, get on with it and experience the difference - crack those interview questions, once and for all.

Did you get to go through Part 1 & Part 2 of the blogs?

Part 1 of the blog:

  1. Stack & Heap - Understand process Stack & Heap
  2. Process vs Thread - How does a thread differ from a process and when to use multi-threading?

Part 2 of the blog:

  1. Out Of Memory - Why does a process run out of memory or hit a segmentation fault?
  2. Fun with Procfs - What is this mysterious virtual file-system named Proc File-system and what is its importance?

Hope the journey through these Bytes presented you with a whole new learning experience. Do let us know your thoughts :)

You've successfully subscribed to Crio Blog
Great! Next, complete checkout to get full access to all premium content.
Welcome back! You've successfully signed in.
Unable to sign you in. Please try again.
Success! Your account is fully activated, you now have access to all content.
Error! Stripe checkout failed.
Success! Your billing info is updated.
Billing info update failed.