11 months ago was the last time I touched firedrake, and last weekend the urge to mess with it caught me again. So I set up WSL, installed all necessary dependencies and opened firedrake. I fired up the last compiled version I had, just to remind myself of where I had left things, and I QEMU was happy to dump my debug printf()’s via the virtual UART into stdout. All was good. Then I compiled firedrake from scratch and it stopped working, or rather, it stopped producing output via the UART. That’s strange, I thought, messed with a couple of things and also stashed all my git changes but no avail; No more output via the UART.

Event Tracing for Windows (ETW) is an incredibly useful tracing mechanism built into Windows, however, it’s not the easiest thing to use. In my day job, ETW is incredibly useful to get profiling samples from customer machines to get insights into performance issues. Since I keep writing the same How-To for everyone, I figured I just write down once here and then link it to people. If you are here because I sent you such a link, welcome!

This is a blogpost I’ve been meaning to write for a long time, it’s about a game Nils and I wrote back in January 2017 for the Inno Games game Jam. That game jam happened together with the global game jam and the topic was: Waves. The source code for the game can be found here

Nils and I both like challenges and even before going to the game jam we had decided to write a game for the original Gameboy (1989) and we decided to write it in assembler. This was inspired by the Ultimate Gameboy Talk at the 33c3 that happened in December of 2016, so we bought a Gameboy Advance and a Cartridge that is capable of reading SD cards. Both arrived about a week before the jam and we hacked together a quick prototype just to get a feeling for the architecture and the instruction set. I also ended up writing an IntelliJ IDEA plugin that supports Z80 assembler and integrated the RGDS toolchain (assembler and linker) as well as the emulator.

X-Plane’s plugin systems allows authors to load models in two ways: Asynchronously and Synchronously. Most plugins tend to use synchronous loading, but since all plugins run on the main thread there is a need and desire for some to use asynchronous loading. Up until now, the latter was broken however, and plugin authors complained about invisible models. From what I understand Pilot Edge were the first to complain, but they want to use async loading to dynamically load in models of planes that flew in via multiplayer, which makes it non-trivial to debug. Luckily, the author of the fantastic Better Pushback also ran into the issue and his plugin is completely local, so it’s no problem to stop at a debugger for any amount of time without being worried a multiplayer socket closes and the whole setup has to be recreated.

This post is about a crash to desktop that I investigated in a popular plugin for X-Plane, X-Assign. This happened in my free time, although I had the advantage of having the X-Plane source code at hand.

Git bisect

My new favourite tool on earth is git bisect, which I used to find the offending commit rather quickly. At this point I wasn’t sure who was at fault for the crash, X-Plane or X-Assign, since the issue only showed up with the update to X-Plane 11.02 and it was working fine in previous versions. The offending commit however turned out to be rather boring, it simply changed the capacity of a couple of datarefs from 100 to 250. Two things about that were interesting though, first of all, the capacity of the underlying variable was already 250, a change introduced in X-Plane 11. Second of all, those datarefs were input related, namely sim/joystick/joystick_axis_values, sim/joystick/joystick_axis_assignments and sim/joystick/joystick_axis_reverse. So not unreasonable that they would be used by X-Assign. The change however, shouldn’t have really broke X-Assign in any way. To figure out what happened, I did was every reasonable person would do: I opened up the disassembler!