Strange * command

RISC OS 5.19 15 Jan 2012 softloaded on on Iyonix.

*s
Internal error: undefined instruction at &FC01E71C
*where
Address FC01E71C is at offset 000001AC in module UtilityModule

There’s no binary called “s” on my Run$Path, in fact this happens with Run$Path not set at all. A bug in UtilityModule?

(edit – still happens on the 30 Jan build)

Interesting – guess I’ll have to take a look at this when I get home.

There’s also another odd bug that I’m aware of – on my RiscPC I’ve got a couple of obeyfiles to move folders around to swap between the 3.7 and 5.x boot sequences. If I run the obeyfiles from the command line just by typing their name, I get an abort, but if I *exec them then they work fine. But since that bug also happens in 3.7 I haven’t felt too compelled to look into it.

That’s a very nice bug you found there! It looks like it was introduced when the hashed *command lookup was added for RISC OS 4. The code that looked up hash values in the special UtilityModule hash table wasn’t checking for null hash table entries. This resulted in the main command table lookup code attempting to treat the UtilityModule module header as a command table. So if you typed a command which didn’t have a hash entry, and that command appears in the UtilityModule header (before the search gets terminated by encountering a null command string) then it would try executing random code and crash horribly. It looks like ‘s’ is the only command which would have triggered the bug, at least in this OS version; perhaps RISC OS 4/6 has a similar bug lurking in it still?

I’ve submitted a fix now, so there should be some nice non-crashy ROMs ready by the morning.

perhaps RISC OS 4/6 has a similar bug lurking in it still?

*s on RO4.02 and 5.16 just gives “File ‘s’ not found” as expected.

RO4.02 and 5.16 just gives “File ‘s’ not found” as expected.

The hash table is generated on boot up in RAM, so differing modules will cause different hash tables to be made. Therefore the bug might exist there, but the exact mix of modules running might result in NULLs for some other non matched command.

*s on RO4.02 and 5.16 just gives “File ‘s’ not found” as expected.

The nature of the bug means that different OS versions might be vulnerable to different commands (or might not be vulnerable at all; 5.12 and 5.16 look to be immune).

Therefore the bug might exist there, but the exact mix of modules running might result in NULLs for some other non matched command.

Not exactly. There are three sets of hash tables in use; the utilitymodule hash table (held in ROM), the system commands hash table (held in ROM), and the main hash table used for all the non-kernel commands (built dynamically in RAM). All three of them have their own lookup functions, but it was only the main hash table code which was checking for null entries. Since the dodgy hash tables are held in ROM, whether ‘s’ (or similar) will cause a crash or not is completely independent of which other modules you’ve got loaded.

There are three sets of hash tables in use

Ah – I didn’t realise that, I’d always assumed one monolith.

I can confirm this seems to be fixed in the 1 Feb build. Thanks :)