While modifying lDebug's ensuredebuggeeloaded, which is responsible for creating an empty process as a debuggee, I erred severely early in the morning of last Wednesday.

The bug was that I moved around a call to .zeroregs (later made into a non-local function) to after the attempt to allocate memory for the new process-to-be. However, .zeroregs uses the ax register, resetting it to zero to be precise. But the allocation, if successful, left the segment of the allocated memory block in ax, to be used to continue the initialisation and eventually call interrupt 21h function 55h to create a child PSP. Passing a zero to the subsequent code made this function call destroy the (linear) first 256 bytes of memory, or the first 64 entries of the Interrupt Vector Table that's located in the first 1024 bytes of memory in 86 Mode. Obviously, this caused a crash.

The insidious thing is that this is a severe, unmistakeable error, that occurs often and reliably, but did not happen in the particular test cases I ran. It crashed when:

• Loading the debugger command line prompt without a debuggee file to load
• Loading the debugger with a binary file to load (filename extension neither .COM nor .EXE)
• The debuggee process quitting by itself and returning control to the debugger
• The debuggee process being terminated by the QA

The only case in which it did not crash, basically, was to load up an executable to run as a debuggee. And even then, only until trying to terminate the debuggee. (However, not when terminating the debugger by entering a Q command to the debugger.) Unfortunately, this slipped past my notice at first. Next, I suspected it might be a new dosemu bug because I first noticed the crash upon exiting the debugger in my recent compilation of the current dosemu2 (located on our server in my home directory's /local.new/bin/ subdirectory). It didn't help that at first I was running lDebugX and lDDebugX with the dpmimini example, so I guessed it might be DPMI-related.

Turns out it wasn't that! It wasn't until the noon of Thursday that I diagnosed and fixed this error.