WindowManager 26bit "Too many tasks"

The Wimp reports “Too many tasks” as soon as it starts up on 26bit with WindowManager 5.85. WindowManager 5.84 also does it; going back further I’m seeing Aborts so can’t confirm the exact version the problem started.

To rule out changes to the !Boot structure, I’ve also tested a clean install:

Repro tested on an A440
1. Extract the latest HardDisc4 on a clean drive
2. Reboot so !Boot is seen, then run !SysMerge from the latest PlingSystem to put the 310 support files into !System
3. Hard-boot

What are the specs of the machine? I’m not seeing any “Too many tasks” or data aborts, but with the latest disc image & PlingSystem I am seeing the following:

• ArcEm, RISC OS 3.11, ARM250/ARM3, 4MB RAM: Boots to desktop fine, but the RMA is bloated to 2MB (can be shrank back down to 1MB in Task Manager, but will presumably cause issues if you’re trying to use a 2MB machine)
• ArcEm, RISC OS 3.11, ARM2, 4MB RAM: Appears to sit forever on the desktop splash screen, before the hourglass appears
• ArcEm, RISC OS 3.11, ARM250, 2MB RAM: Sits forever on the “RISC OS 2048K RPCEmu Host Filing System” without visibly starting to load anything. Pressing Escape prints out a bunch of the Shared C Library’s Messages file (!), entering desktop shows that the RMA’s consumed all the RAM

Arculator behaves the same; the built-in defaults for an A440/1 is RISC OS 3.11, ARM2, 4MB RAM (sits forever on desktop splash screen), changing to ARM3 CPU allows it to boot. 4MB RAM appears to be the lowest that Arculator supports, so I can’t check the behaviour with 2MB, but presumably it’ll be the same.

ArcEm was tested using a local build of the disc image & PlingSystem, Arculator was with the current nightly builds.

I know ArcEm doesn’t emulate the “banked register access after mode change” ARM2 bug, so the hangs must be down to SWP being missing.

Sorry, should have listed the spec. It’s an A440/1 upgraded to an ARM3 with 4MB of RAM, an HCCS IDE Podule providing IDEFS and RO 3.11 ROMs.

I didn’t try to reproduce the issue under emulation, but given what you’re seeing under ArcEm, it might only be reproducible on physical. I’ll build an equivalent RedSquirrel environment and re-test.

I don’t see the issue under an equivalent RedSquirrel environment, so it could well be an erratum as you’ve suggested.

If I can get my A5000 up and running next week, I’ll see if that also shows the issue. I’ve got to resolder 4MB of RAM to the board and get it working first though, so no guarantees!

If you have a debug Wimp Module that produces output to a file, I’m happy to perform whatever testing is required. I’ll also take a look at the Module assembler to see if anything jumps out that might fall foul of errata.

It looks like the ARM2 failure is occurring due to some combination of CLib’s code which checks if SWP is available, and application space being fully mapped out. e.g. CLib does its SWP check, it triggers an abort (which is to be expected), but then instead of invoking the temporary error handler it gets stuck in an infinite abort loop because CLib is trying to use/restore handlers which should be located in application space. More digging is needed to try and discover exactly what’s going wrong.

I tried a clean boot last night (SHIFT-Power On) to Supervisor, “RMLoad Wimp”, then “Desktop” and that hung with a beep around the same point – no visible error though and no way to get to Supervisor. This was to rule out other Modules from !Boot – but obviously assumes WindowManager 5.85 will work without newer Module dependencies.

If I “OK” the “Too many tasks” error I then get an Abort:

Internal error: undefined instruction at &00000000

Which clearly can’t be the case, so either FPEmulator has been entered or the error in R0 is corrupt. Not sure if that tells us anything or not. If I then “Cancel” that error box, I’m dropped to Supervisor with WindowManager still active as I can’t RMKill it.

If I then comment out the !System.!Run line that loads the new FPEmulator and use the ROM version, then cancel the “Too many tasks” error; FPEmulator aborts trying to load the instruction at &FFFFFFFC – which confirms FPEmulator was entered…so there’s possibly a non-ARM2/3 instruction involved or the Undefined Instruction handler is somehow being entered. That all said, I’m not sure if this is a symptom of “Too many tasks” or totally unrelated?

I’ve finally tracked “Too many tasks” down to the HCCS IDE Podule. Unplug the IDEFiler Module and the Wimp then loads, so I’ll take a look at the interaction between WindowManager and IDEFiler and try to figure out why it works with older versions of WindowManager.

The ARM2 problem turned out to be related to the side-effects of the error environment handler being invoked as part of CLib’s SWP detection. The kernel was resetting the CAO to point to the error handler, which doesn’t cause a crash straight away, but can cause a crash later on because the OS will no longer by default protect application space from shrinking. So for *Repeat, it was crashing on return from Wimp_Initialise, because the Wimp had helpfully shrunk application space to zero. This bug has been around for almost 20 years – obviously it’ll only affect ARM2, but I’m still surprised that nobody seems to have reported/discovered it until now.

This MR should fix it. Unfortunately it doesn’t look like it’s going to be related to the problems you’ve been seeing.

Good spot.

I wonder if I’ve spotted two issues. The Filer “Too many tasks” error is likely to be a bug in IDEFiler’s code that worked on early WindowManager. I’ve started going though it’s code, but need to add some debug info to see at which point it fails so I can create a Repro.

The second is the Undefined Instruction abort, which might be a issue in the WindowManager error handler, the Filer Module or stack corruption as a consequence of the error.