Wimp Shutdown fails

Wimp Shutdown no longer drops to the Supervisor and appears to get stuck in the Wimp after its closed all the Wimp tasks.

Repro (tested on a Pi3)

Power on with SHIFT held (primarily to avoid complications with 3rd party Wimp apps)
*Desktop
Press CTRL-SHIFT-F12 twice

Going back through the ROMs I have to hand, it started failing in 5.27 between the 19-10-01 and 20-03-22 builds.

Nineteen years is a long period to look through.

“Shutdown to command line” works with the 2019-11-13 IOMD ROM. It fails with the 2020-01-04 IOMD ROM.

I regret I don’t have any December 2019 ROMs, but at least that narrows it down to a 7-week period.

works with the 2019-11-13 IOMD ROM. It fails with the 2020-01-04 IOMD

11 different ROM releases (not including the two you mention.)

Alt-BREAK clears the stiffage at the mid-grey screen to complete the “Shutdown to command line”.

On the RPi1 the breakage is between ROMs of 19-12-15 and 19-10-21. A diff of module versions shows a change of WindowManager from 5.64 to 5.65.

A softload in PreDesk of a RAM build of WindowManager 5.64 over OS5.29 19Mar22 on the Titanium restores “Shutdown to command line”. A RAM build of WindowManager 5.65 fails so specific confirmation cannot be given at this point.

WindowManager 5.65 is big!! Nightmare!!

(Must own up to not knowing “Shutdown to command line” was even a thing.)

Alt-BREAK clears the stiffage

Good spot, in which case its possibly a Module not shutting down its Wimp task correctly and nothing to do with WindowManager.

A RAM build of WindowManager 5.65 fails so specific confirmation cannot be given at this point.

A RAM version of WindowManager 5.65 has now been built and when softloaded in PreDesk over OS5.29 19Mar22 “Shutdown to command line” fails. A softloaded WindowManager 5.64 is OK. This is on the Titanium

There may yet be more to this.

The fault does occur on an unbooted, *opt 4 0, Desktop.

WindowManager 5.65 is big!! Nightmare!!

You weren’t joking!

The last command the switcher issues shutting down is

*WimpTask Shutdown

I ran MsgMon and Reporter, and found

*WimpTask Shutdown
*Exec
*Exec
*Shutdown

so it is getting stuck after that. In Wimp_StartTask, cut’n’paste checks whether it’s running, and if not then starts itself up. So after the *WimpTask Shutdown, control returns
to the task manager, but now Clipboard Manager is running also.

This means that after the second Ctrl-Shift-F12, Clipboard Manager will be left
as the single task running…

Alt-BREAK clears the stiffage at the mid-grey screen to complete the “Shutdown to command line”.

…and I press Alt-Break and lo and behold see the Clipboard Manager is running!

I also found (going the long way round until I remembered Alt-Break!) another
way to list the tasks running after shutdown:

*Set Alias$Shutdown SDFS:$.Utilities.!Usage

I guess Clipboard Manager is started upon Wimp_StartTask as that marks the move from single-tasking into multi-tasking.

I think it’s up to the Wimp to quit the Clipboard Manager if it’s the last man standing?

I think it’s up to the Wimp to quit the Clipboard Manager

The Wimp sends a message requesting an application to quit, but it’s up to the application to actually do so.

Does it receive the Wimp_Quit message? It should unload itself upon that.

There is also Service_ShutdownComplete, do we get that far?

When it shuts down, the task manager:

1. Does a round of PreQuit’s
2. Does a round of Quit’s
3. Does PostDesk – if you have it
4. Issues *WimpTask Shutdown
5. Opens the shutdown dialogue box
6. Issues Service_ShutDownComplete
7. Returns to its poll loop

This whole sequence happens fine. The clipboard manager gets the message and
quits at step 2. However at step 4 it starts up again, because Wimp_StartTask
always causes the clipboard manager to start now.

Possibly related to this bug: You can also no longer have an obeyfile in PostDesk which calls a BASIC program eg. in LIBRARY

The BASIC program we used just set up a parameter block and called SYS “OS_IICOp” ,xmit%,1

You now get an error on shutting down of “Repeat: Not enough memory” it appears momentarily and the BASIC program (in Library) called from an obey file in the PostDesk directory is no longer being run.

We’ve confirmed the problem on:
RISC OS 5.28 with ROOL hard drive image, a recent 5.29 ROM
Same results using RODs 5.29 release.

In the short term we’ve rewritten it as a transient which works.

“Repeat: Not enough memory"

Oh, so that’s why that is happening.

I think, but may be wrong, that this was one of the many quirks introduced with 5.25 (too many quirks, I reverted to 5.23 until about half a year ago when the kkkkeeeeeyboarrrrd repeat finally drove me mad, but current releases seem much better ;) ).

Possibly related to this bug: You can also no longer have an obeyfile in PostDesk which calls a BASIC program eg. in LIBRARY

Interesting – it is related!

I can make that happen without shutting down. If I quit Clipboard Manager from the
task manager and then double-click on any BASIC program (even just PRINT “Hello”)
I get “Not enough memory”.

The problem is that by the time BASIC starts the application slot has been
shrunk down to zero bytes.

This is because of the Wimp_Initialise in runthetask in s.Wimp07. At that point the currently active object is the Wimp – a module – so the initialise makes the app slot disappear in a puff of smoke.

I found a mention of this change in the docs.

Clearly runthetask needs to be modified to note the slot and restore it, if doing the Wimp_Initialise thing; so that WimpTask can work correctly.

Additionally the Wimp needs to pick up on Service_ShutDownComplete so it knows to not try starting up the clipboard at all in this situation.

Even without quitting Clipboard Manager first, the obey file

Set Test$Dir <Obey$Dir>
WimpSlot -min 640K
WimpTask Resources:$.Apps.!Edit
Run <Test$Dir>.A_BASIC_Program

gives “Not enough memory”. This time the SWI Wimp_Initialise is in Start in s.Wimp01.

We could prevent the slot disappearing in Start and runthetask by
making the Wimp claim its own Service_Memory calls when it’s the
currently active object.

Is the fix not a case of modifying ServiceCode to handle Service_WimpCloseDown and/or Service_ShutDownComplete

If it’s the fact its starting up again after Service_WimpCloseDown is issued, then it surely just needs to track if a shutdown is in progress and not restart?

The task in question is ‘Clipboard Manager’ which is part of the WindowManager module, and the issue affects more the shutdowns. If you do

*WimpTask GOS
*Quit

from outside the desktop, you’ll be left with the same blank grey screen, and have to use Alt-Break to get out of it.

from outside the desktop, you’ll be left with the same blank grey screen, and have to use Alt-Break to get out of it.

So its calling Wimp_Initialise/Wimp_Poll when the wimp isn’t active?

The WimpTask GOS is meant to start the wimp up in single-tasking mode with the command GOS running. But now it starts Clipboard Manager as well, so when you quit GOS you’re left in the wimp with Clipboard Manager as the only task.

Has anyone figured out how to fix this bug without pressing ALT-Break?

My laptop doesn’t have a break key and RPCEmu doesn’t have a “Break” option, so I’m a bit scuppered.

Some laptops push little used keys to alternate combinations,

e.g. Lenovo
Break (FN + B) or (FN + Ctrl + B)

You may need to check your specific manufacturer support pages

If the problem hasn’t been resolved came in with the clipboard copy/paste work, has anyone reported the issue to Andy V who did all that work on windowmanager? Might be worth contacting him, he’s usually super-helpful.

If you don’t know him directly, send me a bug summary on any of my usual addresses, and I’ll pass it on.

Andrew, could you point him at this thread as I detailed the Repro in the first post

I’ve noticed a commit to resolve this issue, has that also rolled into the 26bit Window Manager?