5.30 Stable

which leads to the obvious question of what is blindly loading the System version of the library on the machine that is experiencing this problem?

It is getting loading in by !System.

Putting everything together, this is what appears to be happening:

1) Someone installs Risc OS 5.30 from scratch which includes universal boot
2) They change their ROM version to 5.28 where clib in this ROM is version 6.08 (apparently)
3) System.Run (from 5.30 universal boot) will *RmEnsure that at least 6.19 is running (it is not) so RmLoads System:Modules.clib
4) We now have the version 6.22 that contains SWP running

Potentially a rabbit hole, but on seeing the Pi is a PiAno and Rick’s square bracket comment above. Is there any chance something is connected to the computer’s build? However, it is potentially a moot point if all is good now. (Edit: see Graeme’s post above)

Good to hear you’ve made progress, David. I also expected a webpage, so you’re not alone in that.

Has it also resolved the initial Hermes crashes you reported?

It doesn’t seem to have problems connected to SharedCLibrary etc., the initial problem when I could not send or receive; but there remain Hermes problems due to having more than one email address. If the default send email account is different from the one I am signed into, Hermes won’t send an email from the latter account and gives an error message. I will have to live with that, it seems.

If the default send email account is different from the one I am signed into, Hermes won’t send an email from the latter account and gives an error message. I will have to live with that, it seems.

You don’t have to as I have 10 email accounts set up in Hermes here and they all work even if I am logged in to one , in Messenger.

Make sure you have a SMTP set up for each email account and then in Hermes choices go to the Adresses tab and enter it’s email address.

Do this for each email account and when you are logged in to one account and want to send from another it will automatically do so.

@DavidL: Re Hermes: I was not asking about the addressing problems, but about the Hermes crashes you reported on 7th earlier in this thread.

@Doug
With all the other problems I have had, I saw the choices you mention, but overlooked them. I have entered some addresses in one of them and will see what happens next time I try sending from the several accounts through the one.

@Martin
The problems due to the upgrade of the ‘Hard Disc’, but not the OS, seem to have gone after the OS upgrade. The computer passed Sprow’s HTTP_Client(see above).

I’m a day or so late, but good sleuthing everyone.

I also followed the “install the 5.30 Boot app first, then update the ROM second” and ran into a crash when installing fonts on my Pi 3. The issue went away with the 5.30 ROM and although I didn’t note down the exact error message it looks like I ran into the same issue. It’s good to get a bit of closure around why it happened.

I’d expect 6 on something that doesn’t have SWP.

6 it is.

Well the kernel knows what’s going on at least, that’s a bonus, just for some reason at the precise moment AcquireMutex wants to see that flag it’s the wrong value.

Revisiting this it is possible to reproduce the fault with HTTP_Client and vncserver on OS5.31 after soft loading the Disc CLib 6.22.

I had wondered whether the kernel’s flags were wrong, hence with a 5.28 ROM the softloaded module would capture the wrong value because I had a (faded) memory of changes to OS_PlatformFeatures but looks like Jeffrey did that plumbing in 2016. Since that predates RISC OS running on an ARMv8 there’s no combination in the field missing those flags and not supporting SWP and onto which you would softload CLib.

Probably time to dig out the JTAG debugger and snoop the __swp_available variable for when it gets set. My bet is some allocation happens early before it’s filled in.

Pity ‘Ace’ with Swp couldn’t be added to the Rom for the machines without SWP arm code.

The semaphore implementations are in the shared library code. Since the shared library code is in the OS, and we have the sources to the OS, it’s possible to edit that one place and have it automatically fix all previous applications which use the SharedCLibrary in one swoop.

I have taken the plunge and upgraded the ROM and boot loader files to 5.30. No problems so far, except that HTTP_Client did not return a web page

It looks like a web page to me; it starts with HTTP/1.0 200 OK after all. Is that not how everyone here browses the internet? Next thing you’ll be wanting some kind of graphical interwebs display program…
Anyway, good to hear having upgraded both the disc image and ROM image as a pair you’ve got rid of those perplexing aborts.

If it is any help, I have tried softloading some older versions of clib:

• v6.08 (05 Sep 2020)
• v6.09 (06 Feb 2021)
• v6.15 (21 Sep 2022)

They ALL provoked the same SWP abort, whether 5.28 or 5.30 ROM was in use on my Pi4B.
Note that v6.08 is the version supplied in 5.28 ROM.

Is this really such a long-standing Clib bug, or has something else changed?

or has something else changed?

If I’ve understood everything in this thread correctly, and ignoring the development versions:

• Boot 5.30 will softload CLib if you’re using ROM 5.28
• Boot 5.28 will not softload CLib if you’re using ROM 5.26.

You’re still running into the issue with older CLibs because they’re being softloaded. Previously you would’ve been using the ROM version.

I know this thread is getting rather long, but …

Boot 5.30 will softload CLib if you’re using ROM 5.28

No. DavidL reported the Clib abort on 10th, using !Boot from 5.30 and 5.28 ROM and Sprow’s test program.
I have also reproduced the exact same abort here.

Boot 5.28 will not softload CLib if you’re using ROM 5.26.

I can find no reference to anyone trying ROM 5.26 … but that was effectively 5.24 anyway.

I do have RPi ROMS from 5.24, and 5.28 HD, which I could try tomorrow … but I am not sure if 5.24 will run on a 4GB RPi4B. I could try on a Rpi1B, but I think SWP is available on that, so it would not abort.

No. DavidL reported the Clib abort on 10th, using !Boot from 5.30 and 5.28 ROM

You’ve lost me. With the 5.30 version of Boot and the 5.28 ROM, it’ll softload (the broken) CLib and therefore exhibit the issue, right?

I can find no reference to anyone trying ROM 5.26 … but that was effectively 5.24 anyway.

That was simply a case of the caffeine having not yet kicked in. It was intended as an example of “this wasn’t a problem in the past”.

With the 5.30 version of Boot and the 5.28 ROM, it’ll softload (the broken) CLib and therefore exhibit the issue, right?

You’ve missed a qualifier: you also need to be using an ARMv8 processor (prior to that SWP was available).

It was intended as an example of “this wasn’t a problem in the past”

It’s not yet clear exactly when the problem appeared, so softloading CLib on ARMv8 may have been problematic for many years, it’s just nobody was doing that either because the version in ROM was always newer or the disc image wasn’t requiring it (until the addition of the stubs safety check made it a requirement).

Indeed. Oversimplification (of my own posts) strikes again! :)

@Chris: I think we are both right … Yes, RO5.30 HD will softload Clib if using 5.28 ROM, but will then abort on an ARMv8.

CLib 5.74 12 Oct 2012 shows the issue, but there may have been no need to avoid missing SWPs back then.

The aborting SWP seems to be in k_body AquireMutex, at +16F90 in an expanded v6.22. The question is: how does it get there?

I patched Clib at +16F50 to display the value of O__swp_available in r0 before the TST. After softloading, HTTP_client aborted as expected, but O__swp_available was zero, which explains why it takes the Beq to the SWP.

There are only two places I can see which save the value of O__swp_available. One is in CheckIfSwpAvailable which is only if {CONFIG}=26, so I assume is not assembled.

The other is in _kernel_init, but I can find no trace of the code at _kernel_init being executed when the module is soft-loaded.

Does this explain why O__swp_available is zero, or am I barking up the wrong tree?

Martin’s investigation above prompted an outbreak of improbable lateral thinking!!

Unplug SharedClibrary then restart forcing the Boot to proceed curtesy of the Disc based softloaded CLib. The ‘fault’ disappears.

Verma
 11    -     Unplugged  SharedCLibrary      6.22
 -     8     Loaded     SharedCLibrary      6.22 (29 Nov 2023)    Y

or am I barking up the wrong tree?

Or am I?

I tried your cunning unplug trick, having replaced the softloadable version with my patched one. Rebooted – SharedCLibrary was still listed as unplugged, but the Clib in use was the ROM one (module @&FC… and version unchanged).
StrongEd only listed the unchanged ROM module, not my patched version in RAM.

I saw no strange messages during boot – what did you have to force?
Are you sure it was not somehow using the ROM version?

Rebooted – SharedCLibrary was still listed as unplugged, but the Clib in use was the ROM one (module @&FC… and version unchanged).

Well spotted, the disc CLib was not in use, the test was not valid.

barking up the wrong tree?

guilty

I think that if I set the O_swp_available to 6, the SWP abort is avoided. I have been unable to verify it totally, as it moves around!
But it seems to me it is not being set when Clib softloaded.
And I now have to go out for the afternoon. Damn!

I suppose this isn’t the classic case of a program jumping into the ROMs and running untill it hits something it doesn’t understand !

I have confirmed that if the O_swp_available is zero, and I patch Clib in AcquireMutex so it assumes it was 6, then the SWP abort is avoided, and HTTP_client test completes as it should without error.

The code in kernel.s.k_body at line 394 seems to store the result of OS_PlatformFeatures in O__swp_available, but it is not executed on a Clib softload.

So, I think the question now is: should that code be executed on a Clib softload?

SharedCLibrary 6.23 15 May 2024 fixes the SWP collision.

Very good.

SharedCLibrary 6.23 15 May 2024 fixes the SWP collision.

Gosh! So it does.
I had read the change, and could see no bearing on the SWP problem, and indeed can see no relevance having read it again.
But it is certainly fixed for the HTTP_client test.