Errors and Caret handling

I had a frustrating time recently trying to work out why a simple syntax error in one of my BASIC programs caused the whole system to crash when it was reported with Wimp_ReportError. It turned out to be caret-related (I think) – a dialogue box was open that had the input focus at the point when the syntax error was reached. My generic error-handling procedure reported the error and terminated the task. This then resulted in a cascade of aborts on data transfer, which I’m guessing is because the Wimp was trying to move the caret back to my task’s main window after the task was terminated?

Is that likely to be the correct explanation? Does that mean I’m doing something stupid with my caret-handling? Or does my error-handling need to do some more cleaning-up before closing the task down?

Is that likely to be the correct explanation?

It would seem odd if the Wimp was mucking up placing carets.

Does that mean I’m doing something stupid with my caret-handling?

You neglect to mention – what language, what libraries? Maybe some library code is trying to do something dumb?

Oh, and are you using a recent ROM with the cut’n’paste stuff? Does it behave the same way on an older (say, stable release) Wimp? Just in case you’ve exposed an edge case…

Or does my error-handling need to do some more cleaning-up before closing the task down?

I’d be inclined to simply stick an “exit(0);” (if C, or "END if BASIC) as the first line of you error handling shutdown, and progressively move this through the shutdown code until you trigger the cascading failure. Then, at least, it ought to give an indication of where the problem is happening.

You could also try Wimp_SetCaretPosition, -1 to forcibly disown the caret; see if that makes any difference?

As you’re using BASIC, I assume you have ON ERROR OFF as the first line of the error handler. That generally stops recursive calls of the error handler if it enncounters errors.

You neglect to mention – what language, what libraries? Maybe some library code is trying to do something dumb?

It’s BASIC, and not using any special libraries. It is a recent ROM, with cut-and-paste, though the problem is present with earlier ROMs. I’m sure it’s me doing something stupid, but I guess I was hoping there was some gotcha that might be well known that would explain the errors.

You could also try Wimp_SetCaretPosition, -1 to forcibly disown the caret

I already tried that – still get the crashes. And putting END at the first line of the error handler makes no difference.

As you’re using BASIC, I assume you have ON ERROR OFF as the first line of the error handler.

This is the relevant code:

DIM ErrBlock% 260
ON ERROR PROCwimp_error(REPORT$+" at line "+STR$(ERL))

DEF PROCwimp_error (text$)
ON ERROR OFF
!ErrBlock%=ERR
$(ErrBlock%+4)=text$+CHR$(0)
SYS "Wimp_ReportError",ErrBlock%,1
SYS "Wimp_CloseDown"
END
ENDPROC

It is safest though to do ON ERROR OFF before ANY processing:

ON ERROR ON ERROR OFF: PROCwimp_error(REPORT$" at line "STR$(ERL))

It is safest though to do ON ERROR OFF before ANY processing

Thanks. Even with that improvement, it’s still crashing.

I’m going to have to do some digging to see what’s going wrong. I have a window open that has the input focus. I then open a transient dialogue box over this window, created using Wimp_CreateMenu. This has a writeable icon in it, so grabs the focus. When I click on OK, the dialogue box is closed with Wimp_CloseWindow. It all works as expected, except if there’s an error in the code run when the dialogue box actually does its stuff. In that case, once the error is reported (with the dialogue box still open), all hell breaks loose after the error handler has reported it, despite the fact it should have closed down the task.

If I edit the templates so that there are no writeable icons in the dialogue box, and hence no focus grabbing, then the crashes don’t take place. Something must be trampling over something somewhere, but I can’t see where that might be at the moment.

Presuming that you’ve used a ’modern’+ Wimp_Initialise, you should pass the task handle in R0 to Wimp_CloseDown, and ‘TASK’ in R1.

+ for values of ‘modern’ >= RISC OS 3.00

The Wimp shouldn’t crash and burn that badly from what you’ve described, so I’ve been trying to replicate this to find out why.

I’m using the following piece of thrown-together code:

REM > !RunImage

DIM ErrBlock% 260

ON ERROR PROCwimp_error(REPORT$+" at line "+STR$(ERL))

DIM poll% 256

SYS"Wimp_Initialise",300,&4b534154,"Test" TO ,taskh%

SYS"Wimp_OpenTemplate",,"<SelTest$Dir>.Templates"

SYS"Wimp_LoadTemplate",,0,0,0,-1,"test",0 TO ,winsize%,indirsize%
DIM winbuf% winsize%+4,indir% indirsize%
SYS"Wimp_LoadTemplate",,winbuf%+4,indir%,indir%+indirsize%+1,-1,"test",0


SYS"Wimp_LoadTemplate",,0,0,0,-1,"dialog",0 TO ,winsize%,indirsize%
DIM dwinbuf% winsize%+4,dindir% indirsize%
SYS"Wimp_LoadTemplate",,dwinbuf%+4,dindir%,dindir%+indirsize%+1,-1,"dialog",0

SYS"Wimp_CloseTemplate"

SYS"Wimp_CreateWindow",,winbuf%+4 TO !winbuf%
SYS"Wimp_OpenWindow",,winbuf%

SYS"Wimp_CreateWindow",,dwinbuf%+4 TO !dwinbuf%

SYS"Wimp_SetCaretPosition",!winbuf%,5,,,-1,0

end%=FALSE

REPEAT
 SYS"Wimp_Poll",,poll% TO action%

 CASE action% OF
 WHEN 2:
  SYS"Wimp_OpenWindow",,poll%

 WHEN 3:
  end%=TRUE

 WHEN 6:
  IF poll%!12=!winbuf% AND poll%!16=4 SYS"Wimp_CreateMenu",,!dwinbuf%,!poll%,poll%!4
  IF poll%!12=!dwinbuf% AND poll%!16=1 LIST PRINT

 WHEN 17,18:
  IF poll%!16=0 end%=TRUE

 ENDCASE

UNTIL end%
SYS"Wimp_CloseDown",taskh%,&4B534154
END

DEFPROCwimp_error (text$)
ON ERROR OFF
!ErrBlock%=ERR
$(ErrBlock%+4)=text$+CHR$(0)
SYS"Wimp_ReportError",ErrBlock%,1
SYS"Wimp_CloseDown"
END
ENDPROC

The first window has an input focus; this is passed to the dialogue. Then a syntax error is generated opening an error box and then the program exits as per your snippet.

It doesn’t kill the Wimp for me here though on either the old or latest versions. If the program’s short could you post it in full here, or feel free to email it to me (andy [atsign] vawer dot com) and I’ll see if I can find out what the underlying nasty is.

Thanks

Andy

Yeah, it definitely shouldn’t be doing that, so there must be something else in my program that’s creating instability. It’s quite a big one, so I think I’ll start by stripping it down to see if I can create a more manageable lump of code that still demonstrates the issue. Thanks a lot for the email address – if I get totally stuck, I might wing that over to you if you’re happy to take a look.

Hmm. I just copied your program, created a couple of templates as described, and ran it here. And it crashed when I provoked the syntax error! So that’s odder.

I’m running OS 5.27 from December, IOMD, on RPCEmu (Mac). I’m beginning to wonder if there’s something up with my setup, since I also had strange input focus behaviour with the latest Paint builds that no one else could replicate. Not sure what the best way to investigate this further is, though.

I’ve had problems with StrongED crashing in the past, seemingly due to caret-related issues (I think when StrongED tried to restore the caret to a window that no longer exists?). I think they went away when I upgraded StrongED.

Something to check, if you’re using StrongED on your machine.

If that doesn’t fix it, a Debugger exception dump should help us track down the problem (although that feature doesn’t cope very well with continuous aborts – it’ll keep overwriting the log file, so the first abort, which is often the most useful, will quickly get lost). Also it isn’t totally useful on IOMD because there isn’t enough space in the ROM for the build system to fit the debug symbols (it’ll work, you just won’t get any function names for ROM code)

RPCEmu could be an issue. I have failed to derive the templates file that Andy’s test require. If someone emails me a test I will try here.

pittdj at pittdj dot co dot uk

And investigate the Paint thing.

The latest macOS RPCEmu 0.9.2 build, patch 4, is here

I’m using the following piece of thrown-together code:

I’ve copied this code, and run it on rpi running 5.23, rpi running 5.24 and ARMX6 running 5.25. All fail to crash.

Chris you’re not having much luck with input focuses! It’s a very long shot but I wonder if this has a common cause with your problem with the Sprite File window focus…
Edit: Just realised you already said that! 80)

RPCEmu could be an issue. I have failed to derive the templates file that Andy’s test require. If someone emails me a test I will try here.

I created a template file with two templates. The first created has 5 icons. Number 4 is a menu icon. The second has two icons, of which the second is a menu icon. (I’m not sure whether they have to be menu items – I think not).

click menu over the first window’s menu icon and the second window opens. click on the menu item here and the window closes.

edit: I’ve emailed the files

I’ve had problems with StrongED crashing in the past, seemingly due to caret-related issues (I think when StrongED tried to restore the caret to a window that no longer exists?). I think they went away when I upgraded StrongED.

I ran the test here from within a StrongED window, version 4.69f11. no crash.

I occasionally get wierdness here if Pipedream windows are iconised when an application with the caret quits. Pipedream quits (if I remember right) with an error about “input focus window not found”. It may have been fixed in the latest Pipedream, which I switched to not long ago.

I have the test files now, thanks. I get “Syntax error at line 29” on macOS RPCEmu without anything untoward happening, the Error box clears normally.

I’m running OS 5.27 from December, IOMD, on RPCEmu (Mac). I’m beginning to wonder if there’s something up with my setup, since I also had strange input focus behaviour with the latest Paint builds that no one else could replicate. Not sure what the best way to investigate this further is, though.

It’s looking that way. Do you have any add-on things running?

Well, I’m baffled! I’ve checked I’m on the latest versions of RPCEmu and StrongED, and Andy’s minimal program still crashes reliably, bringing everything down with it. My !Boot sequence is pretty minimal – I’m not running anything strange that I’m aware of, and have stripped everything non-vanilla out of Resources just in case.

Here’s the top end of the Debugger’s report following a crash. I exited RPCEmu after the first of the aborts was reported. If the rest of the dump is useful, let me know and I’ll post here too

Error block: 80000002 Internal error: abort on data transfer at &FC11AA94
R0 = 00000000
R1 = ffffffff
R2 = 00009892
R3 = 000005de
R4 = 000001f2
R5 = 000005de
R6 = 000001f2
R7 = 000004b2
R8 = 000003f2
R9 = 000005de
R10 = 20140bf8
R11 = 20095ea4
R12 = 20004394
R13 = fa207fb0
R14 = 80000000
R15 = fc11aa9c
CPSR = 40000013
R13_usr = 200966e4
R14_usr = fc227fb4
R13_svc = fa207fb0
R14_svc = 80000000
SPSR_svc = 60000013
R13_irq = fa102000
R14_irq = 80000013
SPSR_irq = 80000013
R13_abt = fa301fa8
R14_abt = fc11aa9c
SPSR_abt = 40000013
R13_und = fa402000
R14_und = fc1273b4
SPSR_und = 60000013
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 3 = fa200000, 00008000, 00008000
OSMem16: 4 = fa300000, 00002000, 00002000
OSMem16: 5 = fa400000, 00002000, 00002000
Memory: fa100000 - fa102000
Memory: fa200000 - fa208000
Memory: fa300000 - fa302000
Memory: fa400000 - fa402000
Memory: 00000108 - 0000010c
OSRSI6: 69 = 00000108

R15 = fc11aa9c = WindowManager +a6dc
R14_svc = 80000000 is nowhere in RAM

SVC stack:
fa207fb0 : 20095ea4 :
fa207fb4 : 53a039b0 :
fa207fb8 : 20095a3c :
fa207fbc : 00008000 :
fa207fc0 : 53a039b0 :
fa207fc4 : 20095a9c :
fa207fc8 : 00000000 :
fa207fcc : 20155156 :
fa207fd0 : 8000001c :
fa207fd4 : fc112260 : - Return to fc112260?
         :          : | = WindowManager +1ea0
fa207fd8 : 00000007 : - Return to 00000007?
         :          : | is system workspace
fa207fdc : fc0f6450 :
fa207fe0 : fc09bd40 :
fa207fe4 : fc0106a4 : - fc019198 return to fc0106a4?
         :          : | fc019198 = +19198 in the Kernel
         :          : | fc0106a4 = +106a4 in the Kernel
fa207fe8 : 60000010 : - PSR?
fa207fec : 000600c7 : | SWI XWimp_Poll
fa207ff0 : fc227084 : | R14: fc227084
         :          : | = Pinboard +ebc
fa207ff4 : 201550d4 : | R10
fa207ff8 : 00000006 : | R11                                      - Return to 00000006?
         :          : |                                          | is system workspace
fa207ffc : 20095a14 : | R12

R14_usr = fc227fb4 = Pinboard +1dec
          Function call to fc2281f4 = Pinboard +202c

baffled

Just because RPCEmu seems fine on this 2013 iMac it does not preclude other Mac hardware having some little trick up its sleeve to derail the works.

The interpreter build might be worth a try, it is slower but is a simpler proposition.

If it is thought the that the current OS5 could be harbouring something unfortunate then a second very vanilla instance of OS5 can be made comprising only the ROM and HD4 image.

Did you get this sorted? The ShareFS logon box has writeable icons, and I can often make it crash in a similar way if the Name field is empty but the password field is filled.

Did you get this sorted?

I never got the bottom of it, I’m afraid. As it’s quite an obscure effect, I put it down to a quirk of RPCEmu, but when I get time I’ll try with a totally fresh install, to eliminate anything random that might be causing it.

Out of interest, are you using RPCEmu, or a machine running RISC OS natively?

Yes I’m on RPCEmu as well at the moment, 0.9.3. I just tried the above test code (making a template with test having 5 writable icons and dialog having 2) but the syntax error didn’t make it crash.