Mail Archives: djgpp-workers/1996/12/27/18:11:34
I'm having some problems with v2.01 debuggers locking up with my
editor and I would like some advice on what mods were made to
dbgcom.c so I can work out what's going on (the story is below).
---
(This is under dos/cwsdpmi r3 with emm386 running, everything works
fine under windows (or the 2.00 debuggers))
I have an application (an editor, a tad large to post sample code)
that I can't debug using the v2.01 versions of the debuggers due
to the computer locking up and needing a reset as soon as I start
my code running (usually, some times I can move the mouse, but as
soon as I click a button, the pc locks up).
The unusual things my editor does are:
hooks the keyboard (I know, doesn't work under the debuggers, not a
problem)
hooks the mouse callback
(all code and data for the above functions IS locked otherwise
cwsdpmi would spit the dummy (thanks Charles! EXCELENT debugging
tool))
allocates/resizes additional dpmi memory blocks (on top of any done
by sbrk)
2 or 3 selectors pointing to the screen (wastefull, but the code is
in separate libraries)
frequent calls to int 2f/1680
a couple of calls to dos via int 21 (rather that dpmi int, general
registers only)
calls to the network broadcast message collection function (21/f215)
but via __dpmi_int
the Python interpreter is embedded in my editor but this problem was
occurring before I did that.
As the v2.00 debuggers work with my editor, that is my workaround,
but I decuded to try to fix the problem by looking at
src/debug/common/dbgcom.c. Doing a diff on the two versions of
the file, I noticed a lot of additional code that intercepts the
dpmi memory allocation functions (which I make heavy use of, but
none are called by my code before my pc locks up). I'me wandering if
this or some of the other mods are conflicting with what I'm doing in
my editor.
Thanks in advance for any help and when I get things going, I'll post
the diffs (if any, it may actually be my editor).
Bill
--
Leave others their otherness.
- Raw text -