User Tools

Site Tools


blog:pushbx:2022:0506_embarrassing_ldebug_bug_in_ensuredebuggeeloaded

This is an old revision of the document!


Embarrassing lDebug bug in ensuredebuggeeloaded

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.

Discussion

C. MaslochC. Masloch, 2022-05-07 10:02:21 +0200 May Sat

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.

You could leave a comment if you were logged in.
blog/pushbx/2022/0506_embarrassing_ldebug_bug_in_ensuredebuggeeloaded.1651848307.txt.gz · Last modified: 2022-05-06 16:45:07 +0200 May Fri by ecm