From 941fca8b0d895459c4f2b1acf71b3b000f19eb0c Mon Sep 17 00:00:00 2001 From: Philipp Oppermann Date: Wed, 12 Oct 2016 16:56:25 +0200 Subject: [PATCH] Better Exception Messages: Add example code that triggers the triple fault again (#242) --- blog/post/10-better-exception-messages.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/blog/post/10-better-exception-messages.md b/blog/post/10-better-exception-messages.md index 05d6eb64..3bccf64f 100644 --- a/blog/post/10-better-exception-messages.md +++ b/blog/post/10-better-exception-messages.md @@ -264,7 +264,26 @@ Let's do it by burning it to an USB stick: Replace `sdX` by the device name of your USB stick. But **be careful**! The command will erase everything on that device. -When we boot from this USB stick now, we see that our computer reboots just before printing the exception message. So our code, which worked well in QEMU, _causes a triple fault_ on real hardware. What's happening? +Now we should be able to boot from this USB stick. When we do it, we see that it works fine on real hardware, too. Great! + +However, this section wouldn't exist if there weren't a problem. To trigger this problem, we add some example code to the start of our `divide_by_zero_handler`: + +{{< highlight rust "hl_lines=4 5 6" >}} +// in src/interrupts/mod.rs + +extern "C" fn divide_by_zero_handler(...) { + let x = (1u64, 2u64, 3u64); + let y = Some(x); + for i in (0..100).map(|z| (z, z - 1)) {} + + unsafe { print_error(...)); } + loop {} +} +{{< / highlight >}} + +This is just some garbage code that doesn't do anything useful. When we try it in QEMU using `make run`, it still works fine. However, when we burn it to an USB stick again and boot from it on real hardware, we see that our computer reboots just before printing the exception message. + +So our code, which worked well in QEMU, _causes a triple fault_ on real hardware. What's happening? ### Reproducing the Bug in QEMU Debugging on a real machine is difficult. Fortunately there is a way to reproduce this bug in QEMU: We use Linux's [Kernel-based Virtual Machine] \(KVM) by passing the `‑enable-kvm` flag: