COSC 360 Final Exam for Spring, 2021

COSC 360 Final Exam for Spring, 2021 - Answers and Grading

James S. Plank

Question 1 - 25 points

Here's the answer to the example question. First, let's enumerate the free and allocated chunks, starting from the beginning of the heap. You'll note that the heap starts with a free chunk:

Chunk Start    Size in Decimal   Size in Hex    Allocated/Free
-----------    ---------------   -----------    --------------
0x147d58             40             0x28          Free
0x147d80             56             0x38          Allocated
0x147db8             32             0x20          Free
0x147dd8             64             0x40          Allocated
0x147e18             32             0x20          Free
0x147e38             32             0x20          Allocated
0x147e58             48             0x30          Free
0x147e88            208             0xd0          Allocated

How did I figure those values out? Here's how I did it:

The first chunk is free, starting at address 0x147d58 with a size of 0x28. So, the next chunk starts at address (0x147d58+0x28) = 0x147d80. Note how arithmetic is easier if you just stick to hex and don't bother with decimal.
The next chunk starts at 0x147db8, so the second chunk's size is (0x147db8-0x147d80), which is 0x38 bytes.
You keep going in this manner, until you get to the last allocated chunk, which begins at address (0x147e58+0x30) = 0x147e88. To calculate its size, you can either add up the sizes of the previous chunks and subtract from 512, or you can calculate the last address as (0x147d58+0x200) = 0x147f58. Now, you subtract 0x147e88 from that, and you get 0xd0, or 208. Frankly, it's good to double-check that everything's correct by adding up the chunk sizes and making sure that they are equal to 512.

Now, let's answer the questions:

Question 1: From the table above, 0x147d80.
Question 2: From the table above, 0x147e88.
Question 3: This is a free chunk, so the value there is the size of the chunk: 40, or 0x28.
Question 4: This is four bytes into the chunk that starts at 0x147e58. That should be the flink field of the chunk. Since this is the second chunk on the free list, the value here should be a pointer to the third chunk: 0x147db8.
Question 5: This is eight bytes into the chunk that starts at 0x147e58. That should be the blink field of the chunk. Since this is the second chunk on the free list, the value here should be a pointer to the first chunk: 0x147e18.
Question 6: The pointer returned to the user is 8 bytes into the chunk: 0x147de0.
Question 7: The user's argument is rounded up to a multiple of 8, and then 8 is added to it, so the answer is any value between 49 and 56.
Question 8: Although that pointer is "after" the end of the heap, remember that memory is allocated to your process on a page-by-page basis, and addresses on the same page are treated the same. Since pages are typically 1K - 4K in size, the address 0x147f58 is on the same page as 0x147f57, which we know is legal. So no seg fault.

Grading

Three points per question, with the exception of question 3, which was worth four points.

Question 2 - 5 points

The goal here is to write a program where a child is alive and its parent is not. So, the simplest strategy is to call fork(), have the parent exit instantly, and then have the child sleep and print out the line:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int main()
{
  if (fork() != 0) return 0;    // The parent exits instantly. 
  sleep(1);
  printf("I am an orphan.\n");  // The child waits for a second to print its line.
  return 0;
}

Question 3 - 5 points

A zombie process is a process that has exited, but its parent has not called wait() on it to clean up its exit state. Its parent must be alive, but it hasn't called wait().

Question 4 - 10 points

The sequence of events here should be:

Parent calls fork(), and then wait().
Child calls write() repeatedly to a pipe with no read end.
Eventually that child will generate SIGPIPE (due to buffering -- remember the lecture notes on signals), and that will kill the child.
The parent wakes up from the wait() call and exits.

Now, you can create the pipe in the parent or the child. It's easier if you do it in the child, because then you don't need to close file descriptors in the parent. Here are both answers:

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

/* Have the child create the pipe. */

int main()
{
  int status;
  int p[2];

  if (fork() != 0) {                    // The parent simply creates the child and waits.
    wait(&status);
    return 0;

  } else {
    pipe(p);
    close(p[0]);                        // Close the read end.
    while(1) write(p[1], "Fred", 4);    // Repeatedly write until you generate SIGPIPE
    return 0;
  }
}

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

/* Have the parent create the pipe. */

int main()
{
  int status;
  int p[2];

  pipe(p);

  if (fork() != 0) {                    // Since the parent creates the pipe, it needs to
    close(p[0]);                        // close the read end.
    wait(&status);       
    return 0;

  } else {
    close(p[0]);                        // The child needs to close the read end, too.
    while(1) write(p[1], "Fred", 4);    // Repeatedly write until you generate SIGPIPE
    return 0;
  }
}

Grading

Typically, you started with 10 points, and then received deductions, such as not closing enough file descriptors, writing to a closed file descriptor, no wait() call, etc.

Question 5 - 5 points

This was a garden variety fork-bomb question, of the type I've asked about 5 times in clicker questions. Sure, the loop involves strings, but it's really the same loop, which executes once for each character in the string. The answer is 2^strlen(s).

Question 6 - 25 points

This is a straightforward fork-pipe-dup-exec question. Let's go through what the various processes do. First, the Y process:

It will set up the pipe for E to communicate with D. This has to be set up in the Y process, because Y will create both E and D, and the only way for E and D to share the pipe is for Y to have created it.
It will call fork() twice to create E and D.
It will close both ends of the pipe.
It will call wait() twice to handle the normal condition where E and D exit.
I'll deal with the 10-second issue below.

Next the E process:

It returns from the fork() call with a return value of zero.
It will call dup2(0, 7) so that slencode will read standard input on file descriptor 7.
It will call dup2(p[1], 1) so that standard output goes to the pipe.
It will close extraneous file descriptors -- here just the two pipe ones. It doesn't matter if you close file descriptor zero.
It will call execlp("./slencode", "slencode", NULL).
That's the end -- either the call fails and you return, or the slencodeprogram will take over the process.

The D process is very similar, but it sets up it's I/O differently:

It returns from the fork() call with a return value of zero.
It will call dup2(p[0], 7) so that slencode will read from the pipe on file descriptor 7.
It will close extraneous file descriptors -- again just the two pipe ones. It doesn't matter if you close file descriptor zero.
It will call execlp("./sldecode", "sldecode", NULL).
That's the end -- either the call fails and you return, or the slencodeprogram will take over the process.

Now, the 10-second thing takes some extra care, and you can implement it either with threads or alarm(). The description will be in the answers below.

Question 1: Y calls pipe().
Question 2: It returns from fork() with a return value of zero.
Question 3: It doesn't make any.
Question 4: dup2(0, 7) and dup2(p[1], 1).
Question 5: dup2(p[0], 7).
Question 6: close(p[0]) and close(p[1]). Calling close(0) is optional. Calling close(1) or close(7) is incorrect.
Question 7: From above: execlp("./slencode", "slencode", NULL).
Question 8: We can use threads to handle the 10-second issue: Create off a thread that sleeps for 10 seconds. When it wakes up, it kills the two processes. That will cause the main thread's wait() calls to return, and the program will terminate.
Question 9: Without threads, we can use alarm() to time the ten seconds. The easiest thing to do is to have E and D call alarm(10) before their execlp() call. That will terminate them after 10 seconds, unless Sleven has set up his program to catch SIGALRM. So the easiest thing is not really the best thing.
The best thing is for Y to call alarm() and to set up a signal handler to catch SIGLARM. The signal handler will kill E and D, and then when it returns, the wait() calls will return.
Either answer is ok, BTW.

Grading

Each part was worth 3 points, except question 3 was worth two, and question 7 was worth two.

Question 7 - 15 points

There's a lot of scaffolding to this problem, but I did that so you wouldn't have to waste your time with malloc() and initialization calls. There's not much commentary needed, as the threads simply do what the question asks:


  /* Missing Thread Code. */

  pthread_mutex_lock(s->lock);
  while (1) {
    pthread_cond_wait(s->cvs[p->id], s->lock);
    if (scanf("%d", &num) != 1) exit(0);            // This kills the process when stdin is done.
    printf("%3ld: Thread %d\n", time(0) - s->base_time, p->id);
    fflush(stdout);
    sleep(num);
    pthread_cond_signal(s->main_cv);
  }

  /* Missing Main Code.  It would be OK for you to lock the mutex at the beginning
     and forget about it.  */

  i = 0;
  while (1) {
    printf("%3ld: Main\n", time(0) - s->base_time);
    sleep(1);
    pthread_mutex_lock(s->lock);
    pthread_cond_signal(s->cvs[i]);
    pthread_cond_wait(s->main_cv, s->lock);
    pthread_mutex_unlock(s->lock);
    i = (i + 1) % n;
  }

Grading

Typically you started at 15 points and received deductions. Common deductions were not holding the mutex while calling wait, having your main loop incorrect, not reading standard input correctly, and calling pthread_exit() rather than exit().

Question 8 - 10 points

This one is a little different, because you need the threads to update some shared state, and to signal the main thread when everyone is ready. Here's the code I would write -- it's a little inefficient, because all of the threads signal the main thread. You could make it so that only the last thread signals the main thread, and it would be more efficient.


  /* Missing Thread Code */

  pthread_mutex_lock(s->lock);
  printf("I'm Ready\n");
  s->n++;
  pthread_cond_signal(s->main_cv);
  pthread_mutex_unlock(s->lock);
  while(1);


  /* Missing Main Code */

  pthread_mutex_lock(s->lock);
  while (s->n < n) pthread_cond_wait(s->main_cv, s->lock);
  printf("I'm Ready Too\n");
  pthread_mutex_unlock(s->lock);  // This is unnecessary, but good form.
  while(1);

Grading

Typically you started at 10 points and received deductions. Common deductions were not holding the mutex while calling wait, having a race condition on n, and having multiple threads able to call signal before the main thread wakes up, which means that the main thread cannot count the number of times it wakes up.