Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

UI21DEB deBUGGER released | inreentrant mess (Announce)

posted by ecm Homepage E-mail, Düsseldorf, Germany, 01.03.2009, 16:19

> Thanks.

No problem.

> > Because your hook is inreentrant
>
> This would be a criminal BUG because it was supposed to be reentry-safe
> :crying:

So you see, it isn't. It might be if the code is not traced (so that disabling the Interrupt Flag disables executation of other code because DOS is [supposed to be] single-tasking) but else it doesn't.

> > and JDEBUG ;-) uses Int21 as long as the InDOS flag is not set.
> > The traced Int21 call then probably returns into DEBUG
>
> As long as I don't know exactly what magic/mess DEBUG does on the INT and
> IRET instructions :confused:

It doesn't any. It just calls Int21 between all instructions (you could avoid this by setting my own DEBUG fork's [NDebug's] "assume InDOS" mode, but it's DEBUG's right to do that anyway) so in the beginning of your handler, all used variables like vvstack, vvbckflor and vvbckflid get overwritten with the values DEBUG's Int21 call leaves there.

> > The solution is to set up a reentrant stack frame to get the flags
>
> maybe true ... still, no idea why this should be better :confused:

By setting up a stack frame instead of using the same variables again, each re-entry gets its own private variables (which costs some stack space, but DOS itself uses ~30 bytes user stack anyway) so you can safely re-enter this initial, critical code.

> > and set up your own "InUI21DEB" flag.
>
> But I already have a reentrancy counter !!!

Your reentrancy counter (vvreecnt) would be sufficient if the code really used it (despite the machine halting [?] when it reaches 255). At one point, the counter is set to zero which is probably no good idea (I didn't do much research on that one). The code you're using to decrement the counter is fancy, but I would at least flag an error somehow (which could then be shown when running UI21DEB.COM the next time) if the counter was already zero because that should never happen. The really bad thing about it is that you don't do anything if the counter was not zero when executing the handler: you're re-using the same inreentrant data the previous Int21 call did use (f.e. vvbckax and the other register storage variables), overwriting the previous content. Generally speaking, you don't have to eliminate all inreentrant data and replace it by stack frame variables as long as you only use it one time. You've to skip all usage of inreentrant data when the handler is re-entered (for whatever reason).

Of course MS-DOS's usage of InDOS is not sufficient. Re-entering MS-DOS's Int21 handler during certain time frames will crash the machine without any error message. Microsoft assumes other Int21 users/handlers to take care of not re-entering its handler by not using (most) Int21 functions when InDOS is non-zero.

> > If that is set when entering the handler, completely
> > skip to where you chain to the old handler.
>
> So skip the "hacks" ... but what does this change ? Or do I have JMP to
> original INT $21 instead of CALL'ing it to avoid the "mess" on return ?

Well, jumping to it is not exactly required (although, at least for Int2F hooks, you should chain by jumping whenever possible) but it is required not to re-use any of your inreentrant data when re-entering. If recording of the called functions, applying filename fixes, etc. (hacks applied by UI21DEB) are all coded reentrant, you can still apply these even when your handler is reentered - just manage to serialize (or ignore/skip unserialized) access to the record buffer and any other inreentrant data you use. (The vvreecnt flag can be considered reentrant if only accessed appropriately.)

Feel free to ask more questions.

---
l

 

Complete thread:

Back to the forum
Board view  Mix view
22632 Postings in 2109 Threads, 402 registered users, 341 users online (0 registered, 341 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum