Hints for A0

This file may be updated during the term, so check back periodically.

Quick Topic Links

panic: Out of memory

OS/161 is not very sophisticated in its management of physical memory. Each new thread created by OS/161 consumes some physical memory, but OS/161 does not reclaim and reuse this memory when threads exit. As a result, OS/161 will quickly run out of physical memory and crash. The usual symptom is an "Out of memory" panic, which might look something like this: 
OS/161 kernel [? for menu]: tt2
Starting thread test 2...
panic: threadtest: thread_fork failed Out of memory)
sys161: 1825361101355701675 cycles (130240853 run, 1825361101225460822 global-idle)
sys161:   cpu0: 130240853 kern, 0 user, 0 idle)
sys161: 4859 irqs 0 exns 0r/0w disk 36r/2606w console 0r/0w/1m emufs 0r/0w net
sys161: Elapsed real time: 22.248813 seconds (8.20431e+10 mhz)
sys161: Elapsed virtual time: 22.228067017 seconds (25 mhz)
The best way to avoid this problem is to quit OS/161 after every test. For each test, start the simulator and let OS/161 boot, then run your test, then quit OS/161. Better yet, to save time and keystrokes, boot OS/161, run your test, and shut OS/161 down all with a single shell command line, like this 
% sys161 kernel "tt2; q"

Testing your Kernel

We will test your kernel by running the kernel's built-in thread tests with and without your new dth command. In particular, we will use at least the kernel's built-in tt1 and tt2 tests. You can test your work the same way.

For example, we will compare the output of this kernel run 

% sys161 kernel "tt1;q"
with the output of this one 
% sys161 kernel "dth;tt1;q"
to check whether we see DB_THREADS debugging messages in the latter case but not in the former case.

GDB tips

Note that the YouTube channel for CS 350 contains a video tutorial on how to use gdb. In addition there is some information included below.

If you type < ctrl-g > in the sys161 window, the OS pauses and waits for a debugger to attach. This is useful if you don't have a debugger already attached and you want to see what's happening.

If you create a file called .gdbinit and put it in $HOME/cs350-os161/root directory (assuming that is where you are running cs350-gdb from) gdb will load commands from that file when it starts up. Here's an example of a simple, useful .gdbinit file: 

dir ../os161-1.11/kern/compile/ASST0
target remote unix:.sockets/gdb
break panic
This way, you don't have to type the target command to connect to sys161 every time you run the debugger, and you don't have to type the dir command to tell gdb where to find your build files. This .gdbinit also sets a breakpoeint at the kernel's panic function, so that gdb will grab control in case the kernel panics. Note that you will want to change dir ../os161-1.11/kern/compile/ASST0 for subsequent assignments, e.g, for assignment one, your .gdbinit file should contain dir ../os161-1.11/kern/compile/ASST1 instead.