Airline Entertainment System crashing WTF
-
Found this off slashdot. It's a mistake I see all too often in code.
http://blogs.csoonline.com/node/151
-
google cache:
<font color="black" face="arial,sans-serif" size="-1">
http://www.google.com/search?q=cache:WbncwCBDKysJ:blogs.csoonline.com/node/151+http://blogs.csoonline.com/node/151&hl=en&strip=1</font>
-
@microsage said:
Found this off slashdot. It's a mistake I see all too often in code.
http://blogs.csoonline.com/node/151
This is a fantastic bug. It reminds me of a bug we had back in university embedded-systems course. My partner was in charge of writing the screen output library for text output. We had two text-output calls: PRINT() and DEBUG(). With a compiler directive, you could suppress DEBUG messages, and DEBUG messages appeared in a different colour than regular messages so you could know what you're looking at.
Our programs ran fine when we weren't debugging, but every once in a while everything would lock up and die violently if we were. We couldn't figure it out. Then it dawned on me:
The PRINT and DEBUG calls had to loop from the end of the screen to the beginning so that we could output an arbitrary number of messages. PRINT checked if the current line was 24, and if so it looped. DEBUG checked if the current line was 25, and if so it looped.
As we all know, simple text output occupies the memory addresses 0xF000 (or something - it's been a while) through 0x10000. Our boot loader loaded the kernel into the address 0x10000. When the correct sequence of PRINT and DEBUG messages were called, the checks passed and the output functions stopped looping. Any subsequent calls to the output functions wrote arbitrary strings into kernel space, causing all hell to break loose.
The fix was just a matter of changing == to >=. I never let my partner live that one down. After that I was in charge of all output functionality.
