TaskWindow abort

The TaskWindow module will abort (on instruction fetch!) when no TaskWindow server is running and you run the command *%TaskWindow -Display -Ctrl

It’s the combination of the Display and Ctrl switches that seems to cause the abort. *%TaskWindow -Display is fine and so is *%TaskWindow -Ctrl "Echo Test"

This is a very old bug that was already around in Acorn days, perhaps it’s time for some fresh eyes to have a look at it and see if it can be fixed.

A debugger dump shows that we are in inittask > GetParentTask > SetWimpKeyStates > SetKeyStates.

inittask is user mode code running on MyVecStack.

The only place key_ctrl is read is in MyWrchV, so I set the BEQ to BAL here. This stopped the crash, which shows that the MyWrchV is indeed being entered, whilst we are still in inittask.

The code that reads key_ctrl (to check if -ctrl was used), is also running in user mode on MyVecStack. So it is likely the vector handler is clobbering the inittask stack.

The incomplete stack annotation from debugger, and the branch through zero are also suggestive of a stack problem.

I don’t know what is triggering the WrchV, but I expect the solution to this bug will be to initialise PassOnVectors to 1 rather than 0 in inittask, so no other code tries to use MyVecStack while we are still using it.

Happy new year :-)

Actually there are two stacks: MyVecStack and CommandStack. The vector routine MyWrchV runs on MyVecStack, but inittask is running on CommandStack, so the corruption can’t be happening the way I thought.

What’s going on? Because we have -Display, we call GetParentTask in inittask so there is somewhere to pass output. This broadcasts a Wimp message to ask for a parent to adopt us, but there’s no task window server running (as specified in the bug report), so instead we have to start one ourself. It is just before we call the Wimp_StartTask for this that we go into SetWimpKeyStates. Presumably that routine then causes some control sequences to be issued, which wouldn’t be a problem except we are also using the -Ctrl option, so rather than ignoring those characters in MyWrchV we try to output them which means we call GetParentTask to ensure we have somewhere to send them.

Therefore we end up re-entering GetParentTask. Why this would cause the apparent stack corruption I don’t know.

Thanks for looking into this!

If we do end up in MyWrchV calling GetParentTask doesn’t that mean we’re entering a loop? Because as no TW server has been started yet we’re going to try that again. Resulting in calling SetWimpKeyStates again, entering MyWrchV again and calling GetParentTask again.

Given that MyVecStack is small (32 words) this should exhaust the stack very quickly.

Also, would it actually safe to try to start an application from vector code?

and calling GetParentTask again.

In the vector code, that call is protected by PassOnVectors = 1, so shouldn’t re-enter again.

I think if someone wanted to really work out why it crashed they’d be best turning on all the debugging output.