Potential bug relating to something calling PDriver?

For the little test program that I wrote to see what flags OS_File 255 returned for a non-existant file (see other thread), running it in a TaskWindow gave a massively wide memory dump – not so good for a forum post.

So I went to the command line and tried to *Spool it to a file. Instead of the expected error, I got this:

Address  :     7 6 5 4     B A 9 8     F E D C     3 2 1 0 :    ASCII Data
20002044 :    000001E6    20495753    31303826    6E203634 : æ...SWI &80146 n
20002054 :    6B20746F    6E776F6E    20746F00    6E756F66 : ot known.ot foun

It works fine when printing to screen. It fails when spooling. From the command line, no less, so it’s nothing to do with TaskWindow.
I currently have no part of Printers loaded.

I’m just wondering if anybody else is seeing something like this?

It’s not a bug, it’s a “feature”.

The error will almost certainly be stored in one of the shared error blocks that MessageTrans uses when it translates errors. Those error blocks can get overwritten pretty quickly if you continue to call SWIs after receiving the error. Solution: make your own copy of the error block (on the stack, or into a pre-allocated buffer) before calling any other SWIs.

Hmm… I’ve tracked it down to some code that runs as a callback. It checks to see if there’s a current printer job, to not do what it does if there’s an active job. Side effect, SWI not known messes up the error block.
I can’t check to see if the module is present (lookup name), absence messes up the error block.

I wonder if I could pick up the user mode CPSR to see if V is set? (and check SPSR for the same reason?)

I wonder if I could pick up the user mode CPSR to see if V is set? (and check SPSR for the same reason?)

That’s not really possible (the values will be buried in different places in the stack, depending on OS version).

Also, it shouldn’t be necessary. When a SWI returns an error to user mode with IRQs enabled, and the error block looks like it’s in writable memory (i.e. it’s located below ROM), the kernel will temporarily block callbacks from being triggered in order to avoid callback-based code overwriting the error blocks (CBack_Postpone flag). That callback block will be removed on the next SWI that returns to user mode with IRQs enabled – which should be enough time for any code which cares about the error to have interrogated the error block.

Flaw: Because the second SWI will clear the flag, if that second SWI is also returning an error then that block won’t be protected. I guess a workaround would be to call a dummy SWI like OS_IntOn to force the flag to be cleared before you call the second SWI.

Those error blocks can get overwritten pretty quickly

Yup, one of the “features” of RISC OS. ;-)

the kernel will temporarily block callbacks from being triggered in order to avoid callback-based code overwriting the error blocks

Clever.

Revised program:

DIM x% 255
DIM err% 255
SYS "XOS_File", 255, "$.nofilehere", x%, 0 TO r0% ; f%
IF (f% AND 1) THEN
  FOR l% = 0 TO 252 STEP 4
    err%!l% = r0%!l%
  NEXT
ENDIF
PRINT r0%, f%, (f% AND 1)
OSCLI("Memory "+STR$~r0%+" +20")
OSCLI("Memory "+STR$~err%+" +20")

Does this:

*_test
536879940         5         1

Address  :     7 6 5 4     B A 9 8     F E D C     3 2 1 0 :    ASCII Data
20002344 :    000001E6    20495753    31303826    6E203634 : æ...SWI &80146 n
20002354 :    6B20746F    6E776F6E    20746F00    6E756F66 : ot known.ot foun

Address  :     3 2 1 0     7 6 5 4     B A 9 8     F E D C :    ASCII Data
00009110 :    000000D6    656C6946    2E242720    69666F6E : Ö...File '$.nofi
00009120 :    6568656C    20276572    20746F6E    6E756F66 : lehere' not foun
*

So there’s the answer. ;-)

The problem here is probably the OSCLI command, which will call XOS_CLI to do its bidding.

I wonder if there might be some value in – if the SWI returns with V set – having BASIC immediately copy the error block into its own workspace and fiddle R0 to point to that instead? Then whatever else goes on in the system won’t mess up the error message that the user can retrieve from their own code.

which will call XOS_CLI to do its bidding.

No, it looks like most of the SWI calls in BASIC are non-X form, and ChangeEnvironment sets up a centralised error handler to deal with them.

I wonder if there might be some value in – if the SWI returns with V set – having BASIC immediately copy the error block into its own workspace and fiddle R0 to point to that instead? Then whatever else goes on in the system won’t mess up the error message that the user can retrieve from their own code.

Maybe, yeah. That’s essentially what C does if you use _kernel_swi (errors get copied to the buffer used by _kernel_last_oserror)