[gccsdk] Threading + Alt-Break = Trashed Computer

Ben Avison bavison at riscosopen.org
Mon Jul 14 15:20:47 PDT 2008

Adam <lists at snowstone.org.uk> wrote:
> What's the way forward for this? Even if the optimum solution does
> turn out to be an OS update, is there some interim solution, or can the
> OS functionality be updated in a piecemeal fashion? Where does the
> watchdog code reside?

The Watchdog is part of the Wimp - it needs to be in order to have access
to the list of active tasks, their AMB handles, environment handlers and
so on. Ideally, the Watchdog would be fixed to call the exit handler of the
task being killed, but it's not a trivial fix, as I've been trying to
explain [*]. ROOL-based Wimps could be built such a theoretical fix for OSes
3.10 - 4.02 and 5.xx, though other versions would need to be developed by
ROL or perhaps be patched.

The alternative is some sort of module or application watching for the
service call or Wimp message, as discussed earlier, but that would catch
lots of false positives.

Maybe if UnixLib's problem stems from a task handle being reused when the
old task never had its exit handler called, it would be wise instead for
the thread initialisation code to check whether the current task handle is
one which it thought it already knew about and forget about the old task at
that point.

>> Now imagine that the exit
>> handler has a bug that means it goes into an infinite loop if the
>> handler isn't installed (maybe it used a non-X SWI to deregister the
>> handler and an error is generated, which would then call the exit
>> handler again).
> At the risk of revealing my ignorance... Doesn't this case depend on a
> signal handler invoking the exit handler, which then raises a signal and
> so on? In which case this is not possible when using UnixLib as I'm
> pretty sure it traps recursion in a signal handler.

In this case, I'm talking about the OS exit and error handling systems,
which sadly will quite happily recurse. The Watchdog isn't in a position
to assume that any task it might kill would be using UnixLib. ;) Besides,
this is just an example, I'm sure there are other ways in which an exit
handler can fail to complete.

> The UI for the Watchdog could do with some work in general ;)

Indeed, I doubt anyone would have chosen error boxes as a UI if it weren't
for the ease of implementation. I know I've hit "Next task" one time too
often on many occasions! The problem is that the Wimp wasn't written with
"modal" windows in mind, which by its nature is exactly what the Watchdog
needs to use. The Wimp has a duplicate set of window redraw, keyboard and
mouse code for the error box so that it doesn't have to use Wimp_Poll events,
and I guess the Watchdog implementer didn't fancy doing that all again for
another window.


[*] Actually, I've thought of a further constraint: I don't think anything
has ever prevented an exit handler from calling Wimp_Poll, and such behaviour
may well be desirable in some cases. This means that Wimp_Poll should really
be capable of resuming the task that was interrupted by the Alt-Break, so
maybe the best approach is for it to have its saved state faked up to look
like it has called Wimp_Poll with a pointer to a high-priority non-zero
pollword (the highest priority event) and the saved PC pointing to a cleanup
function that reinstates the SVC stack before exiting the key event handler.

More information about the gcc mailing list