[didnt know if this is more OffTopic or Discussion, as this is a delphi related story]


[didnt know if this is more OffTopic or Discussion, as this is a delphi related story]
Currently i feel like having christmas and birthday at the same time. I managed to track down a bug in my application which bothered me for quite some time now(a few month to be more accurate).

As iam working on an IDE/Compiler/Emulator/Debugger for a virtual system, i use already written samplecode to test my own system. Someone has written a tetrisclone. This one runs fine, except for one dead "Pixel" which is black instead of being colored. I could not figure out the problem, and to top it all, the programm wasn't available as assembly text, but as hexdump only.

No point to start and no clue where the problem was(everything worked, in every program, except for this pixel in THIS program) i stopped thinking about it after i spend countless hours on checking my operations and assembler/compiler.

Then, a few days ago, i finished my debugger for the system. This time i rearranged the hexdump, so it had only one hexvalue(word-sized) per line and stepped through the dump. After an anoying stepping session, i found the section in the hexdump, being responsible for drawing the purple box, which missed the pixel. I disassembled the section with a dissasembler i found somewhere, replaced the hexsection with the dissasembly, recompiled it and stepped through it, again.

The problem was a line with the adress statement [A + 0xFFFF], A Being a register in this system. The address evaluated at this line represented the pixel at the screen..or should have. as it turned out, my emulator did not implement adresswrapparound for this particular statement and the result was somewhere else to find in the memory

Its sometimes really aqward how long it takes to find a bug, compared to the time fixing it. Adding a simple MOD to the internal calculation fixed it -.-

In the screen below, you see the old result on the screen on the lower right. The screen in the middle is the paused drawing process. The red circle indicates the operation and the pixel it results to.

Dont get irritated by the black space between the windowborder and the actual graphics on the current screen. Thats on purpose.

Maybe someone else wants to share his personal Debugnightmare to ;)

Comments

  1. What the hell platform does this assembly language correspond to? :)

    ReplyDelete
  2. Ilya S This assembly language corresponds to the virtual cpu DCPU16. On 0x10c.com on the right side, there is a link for the documentation which includes the CPU and all currently known devices

    ReplyDelete

Post a Comment