[gccsdk] Threading + Alt-Break = Trashed Computer

John Tytgat John.Tytgat at aaug.net
Mon Jul 14 16:22:01 PDT 2008


In message <op.ueay0yepl0n5eg at balaptop.ba>
          "Ben Avison" <bavison at riscosopen.org> wrote:

> Maybe if UnixLib's problem

By now I don't consider this issue as an UnixLib problem.  Wimp Watchdog
implementation is wrong by not always calling the task's exit handler, at
least not as first attempt.  The 'excuse' that this exit handler might be
'rogue' is a bit poor IMHO as we have the exit handler called in many other
cases (including Watchdog killing the current task) without considering this.

Also a second attempt can fail or be ignored when e.g. callbacks can't
kick in so it's really an all bets are off situation.

> 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.

For this particular case, I would perhaps focus our attention on the Filter
module.  You can question if the Filter module shouldn't be made a bit
more robust by making its registered filters inactive (note: 'inactive',
not deregistering itself) when that which got registered for specifique
tasks which got killed.  The Filter module could use the service call
Service_WimpCloseDown for this.

That would prevent a rogue filter rule become applicable again for a new
task which just happens to get an older task handle which the Wimp reused.

I guess this is a very simple improvement and would solve Adam's case too.

But still I believe a task exit handler should always be called when that
task gets killed, at least as first attempt.  A second attempt to get the
task simply thrown out by the Wimp is an acceptable last resort.

> >> 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.

True.  Environment handlers really need to be written robust and bullet
proof.  Sadly this is a bit of a weak design in RISC OS.  :-(

> [...]
> [*] 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.

My PRM 1-294 clearly says that when exit handler is called you should
restore task's handlers and call OS_Exit.  Any task calling Wimp_Poll again
is clearly off ground here.  No ?

BTW Ben, thanks for your feedback and insight. I learned a lot from this.

John.
-- 
John Tytgat, in his comfy chair at home                                 BASS
John.Tytgat at aaug.net                             ARM powered, RISC OS driven




More information about the gcc mailing list