A Ghost in My Machine or an Interesting Bug?

Do you remember Isaac Asimov’s theory of ghosts in machines?

If I’m not mistaken, it was introduced in the book I, robot. It described a situation when some random fragments of data or code blocks could combine in one big piece called a fractal. Then, in some specific situations, that big fractal of random data and programs could be executed, which could cause some new unexpected behavior of robots or computers.

Robots could then see dreams from those random fractals. Sounds like computer evolution based on a random combination of programs, data, and some memory garbage.   

That is cool story for other people but sounds like a nonsense to any software developer.

We all know that any undefined behavior of code leads us to application crashes or some exception. Sometimes, it causes program hangs or incorrect output. For the worst scenarios, developers create software or hardware watchdogs which should detect unexpected behavior and reboot the system.

When data and programs combine with each other in unexpected forms we probably can see a fractal of bugs but not the “computer’s dreams.” So a machine ghost is just a big bug, isn’t it?

Today, I’ll tell you about my observation of a machine ghost in action.       

It was a winter day, and I had nothing to do, so I decided to perform some training sessions. I got a simple chip Atmega16 and wanted to create some firmware for it. I wanted to test some developer tools, learn some skills, and have some fun. After I ran the simplest program on chip to blink LEDs on different pins, I proved the developer tools and started actual coding.

The firmware I wanted to create was very easy: simple calculation on the chip and some communication via UART. UART is a 2 wires serial port so different devices can send and receive bytes between each other. Then I planned to use UART-USB converter to connect Atmega16 to my PC and communicate with a chip from my computer. Also, I created a small desktop app to send and receive bytes from USB and log those bytes in a file. A piece of cake.           

I created the firmware quickly, but after deploying, the chip was responding in UART incorrectly, so I needed to debug my program. Since I did not have useful debug tools, I decided to use the same UART port to send some debug data on PC.

I added in different code blocks of my firmware, the sending of some byte constants, so when I get byte sequence on my PC, I can understand how firmware code was executed, which blocks are missed, do I have endless loops etc. I used purely random byte constants on different code blocks. Obviously, the communicating data was going to mix with debug constants (since I was using the same UART port), but I expected to separate them easily in log file.

So, I started to implement my debug plan, and initially, everything was good. I got my debug data, analyzed it, and added more new debug constants to clearly understand what was happening with my firmware. Later, I added more and more debug constants and got longer and longer debug sequences and at some point my PC lost its mind.           

Imagine the context menu of your Windows desktop appearing and disappearing on different points of your desktop with high frequency. Crazy context menu. You can’t use the mouse because the cursor is jumping on the desktop and calling context menu on different places. You can’t use the keyboard to handle your PC, because you can not have the focus on any element, since the focus is always broken by the context menu. This is the situation I saw during my debugging. I had no idea what was happening and my guesses were:

• my touchpad had broken at some point, and it was sending broken data to the laptop.
• OS got single bug, and the PC lost its mind.
• I got some bug in remote desktop app I was using too.           

It was late evening, and I was tired so I decided to handle this situation the next day with a fresh mind. I turned off my PC in the hard way, because with the crazy context menu, I couldn’t even turn off the PC.           

On the next day, I turned on my PC and decided to not use the remote desktop app to exclude any possible bugs from it. Everything was going good, so I checked the log file I collected during the last debug session which was interrupted by the crazy context menu. In the logs, I saw the mess. I expected to find in the logs some mix of debug byte sequence and communication data. Except I also saw a lot of garbage of random similar bytes I did not send from chip to PC, neither as debug bytes, nor as communication bytes. That was weird, and I did not think my crazy context menu issue could affect the data sent from chip to PC. It was looking like white noise appeared on UART wires because of bad connection or external influence.           

Since it is hard to analyze white noised data, I decided to repeat the debug session to collect clear log file, but when I started the new debug, the crazy context menu was back. After a reboot, I found white noise logs again. I repeated it again and got the same result.

That was unexpected but interesting.

Later, during next debug session with the crazy context menu, I just plugged out the USB connector with Atmega16 chip and context menu issue stopped. Then, I plugged in Atmega16 USB connector and the context menu issue started. So, the crazy context menu issue definitely was caused by my firmware of Atmega16 chip, and after a short time, I understood the whole issue.           

The thing was, the data I was sending from chip to PC was interpreted by Windows as a data sent by USB mouse, and all my debug random bytes were executed as mouse actions (right button clicks with random moving of cursor on the desktop). It did not occur initially and appeared later after I added more debug bytes sent in UART to have more detailed logs.

WOW! It was a huge relief for me! Just imagine random bytes combined in random sequence, mixed with communication bytes matched with the byte sequence of actual device (mouse), so Windows started to execute unexpected mouse events on PC. I had create an external mouse clicker trying to debug my simplest chip firmware! And the most interesting thing is how random mixed parts of data combined in some new entity which I had not expected to see.           

Is this the simplest machine ghost (or computer dream) Isaac Asimov was talking about, or just an interesting bug?

I don’t know, and I’m not sure what the white noise I received from USB port in my logs was, but I guess it was the actual bytes from my mouse. I think when OS started to interpret my debugs as “mouse,” it started to merge my debug data and actual data from touchpad and send that mix through one port where I received and logged that data mix.

Whether you believe in the Ghost in the Machine or not, most everyone can agree that good software development is important. If you need the right technology partner to help your business succeed, schedule a free assessment.