Mail Archives: djgpp-workers/1996/12/30/13:32:10
Hi All:
Bill wrote:
> 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).
Amazing, I have a similar problem with my editor (the one inside of
RHIDE)!
>
> ---
>
> (This is under dos/cwsdpmi r3 with emm386 running, everything works
> fine under windows (or the 2.00 debuggers))
If I use CWSDPMI the machine locks after some operations of the
debuggee, if I use Win3.1 all works OK (puaj, puaj and puaj).
In my case I started with this problem after an upgrade from a 2.01
dated on the middle of october to one dated on 31/10, I'll try to
find the old files to replace and see if the problem goes away.
>
> 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).
In my case the editor starts, loads the previous state (all the
windows that the user had opened) and when the TVision starts to poll
the Mouse/Keyboard the program gets freeze, I must press the RESET
button and of course I ever loose some data (the RHIDE project for
example).
>
> The unusual things my editor does are:
> hooks the keyboard (I know, doesn't work under the debuggers, not a
> problem)
Works if you chain to the original handler. My editor doesn't hook
the kbd because Robert doesn't like that.
> 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))
In TVision the mouse is hooked too, if some thing is not locked
CWSDPMI reports a GPF in the RMCB so as you say the problem isn't a
paged out routine.
> allocates/resizes additional dpmi memory blocks (on top of any done
> by sbrk)
I don't make that.
> 2 or 3 selectors pointing to the screen (wastefull, but the code is
> in separate libraries)
TVision uses __dos_ds and the PrimaryScreen stuff.
> frequent calls to int 2f/1680
> a couple of calls to dos via int 21 (rather that dpmi int, general
> registers only)
TVision doesn't make that.
> calls to the network broadcast message collection function (21/f215)
> but via __dpmi_int
TVision doesn't make that.
> 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.
I guess that the mouse callback is the most hard thing that TVision
does, and you are making the same, so may be there are some
interference, but in my case all worked with the old v2.01 so may be
is one of the last minute corrections.
>
> 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).
The same, but isn't only your editor, I thinked the same when does
happened.
SET
P.S. The first time that I saw that was in machine with low memory (8
Mb), but when I tried at home (20Mb) I got the same problem. My
workaround was using Win3.1 but that sucks!.
--------------- 0 --------------------------------
Salvador Eduardo Tropea (SET).
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013
- Raw text -