apratt@atari.UUCP (Allan Pratt) (08/27/88)
The author of "break" (L.J.M. de Wit) has committed one of the cardinal sins of TOS programming: he has used the location of an OS private variable in his utility code. He uses the address of GEMDOS's current-process variable. He uses this to follow the parent's-basepage list up, to see if he is about to terminate the Desktop. Moreover, he doesn't check to see whether he is a second-level interrupt. If the IKBD interrupted some other interrupt (possible but unlikely), this program will crash hard. Something that fixes both of these problems is to check the stacked SR from the interrupt. If the processor was in User mode, you know (A) it isn't the desktop, and (B) you aren't a second-level interrupt, therefore (C) it's safe to call Pterm when you return. If it's NOT safe, the ctl-delete should be removed from the queue. That way, it's like it never happened. This means it might take several Ctl-Deletes to stop a process, but the ones that don't stop it also won't do any harm. I suggest the author take his code apart and look into these changes.. The worst part is the absolute-variable-location problem -- this makes his code ROM-version dependent, and he doesn't even bother to check the version number! ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
to_stdnet@stag.UUCP (08/30/88)
From: dal@syntel.UUCP (Dale Schumacher) [apratt@atari.UUCP (Allan Pratt) writes...] [...2 problem descriptions...] > > Something that fixes both of these problems is to check the stacked SR > from the interrupt. If the processor was in User mode, you know (A) > it isn't the desktop, and (B) you aren't a second-level interrupt, > therefore (C) it's safe to call Pterm when you return. This won't do you a whole lot of good if you're stuck in an OS call, like waiting for a keyboard character, or doing disk i/o. The window where the program (user mode) has control could be VERY small, maybe too small to hit between disk accesses. > If it's NOT safe, the ctl-delete should be removed from the queue. > That way, it's like it never happened. This means it might take > several Ctl-Deletes to stop a process, but the ones that don't > stop it also won't do any harm. Then I hit Ctl-Delete several times, maybe letting the key repeat in order to hit the tiny "breakable" portion of the code, and the program DOES finally stop, but now I have several "break" keys in the buffer, and the SHELL I'm running will now break. Maybe the program should be rigged to clear the keyboard input buffer on program termination, or better yet, ignore breaks for some fraction of a second after the program terminates (easy to do by checking 200Hz clock values). -- Dale Schumacher 399 Beacon Ave. (alias: Dalnefre') St. Paul, MN 55104 ...pwcs!stag!syntel!dal United States of America "Man who says, 'It cannot be done', should not interrupt man who is doing it." -Ancient Chinese Proverb