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:
.COM
nor .EXE
)
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 debuggee 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.
Discussion
Because it took more than a day to find and fix this bug, the 2022-05-04 current release build of both lDebug and lDDebug are affected by this bug.