WindowManager and Wimp_SetCaretPosition

I have had a report from a user testing this morning’s v5.27 ROM (15/12/2019) of a Data Abort in Organizer that appears to be in the Wimp_SetCaretPosition SWI. The abort seems to be at WindowManager @ &FC1379B0 +&115A0.

The aborting BASIC statement is
SYS "XWimp_SetCaretPosition",window%,icon%,,,-1,L%

This was on a Titanium, and I do not have parameter values, the registers or the affacted code, but I have downloaded a new RPi ROM and I will try to get further information when I can get that running.

Something to do with the WIMP cut/paste additions maybe?

https://www.riscosopen.org/forum/forums/3/topics/14939

It seems a little unlikely, but do we know that the compiler issues identified the other week don’t affect any other non-64-bit-value parts of the build? The Wimp doesn’t use C anywhere directly, does it?

Jeffrey’s ticket doesn’t seem to have progressed, so I’m assuming that nothing has been changed in the nightly-build toolchain since the problem was spotted?

The Wimp doesn’t use C anywhere directly, does it?

Certainly didn’t show any evidence of C use when I last looked, but there a lot of inter-dependencies in the Desktop overall.

Rather than Bryans forum reference I’d refer to the actual source code change for bits that Organizer may be accessing.

Certainly my suspicions were that the CnP Wimp changes are the cause – made stronger now I have reproduced it here on my RPi. Further details are…

SetCaretPosition Debug details              Mon 16th Dec 2019  10:28

RISC OS 5.27 (15 Dec 2019)
C Library 6.03 (27 Jul 2019)
BBC BASIC V 1.77 (29 Jun 2019)
Window Manager 5.65 (14 Dec 2019)

SetCaret parameters (call 1)
  Window ~s%=&20CF78D9 Icon w%=7 Position L%=0

SetCaret parameters (call 2)
  Window ~s%=&20CF5879 Icon w%=-1 Position L%=0

10:28:18.94 ** Error **
  Error  : &80000002
  Message: Internal error: abort on data transfer at &FC15ED9C
10:28:18.94 Organizer 2.28a (18 Apr 2018) Martin Avison (Demo) : Err
** Error ** ERR=&80000002 Internal error: abort on data transfer at &FC15ED9C ERL=11429

Memory: Prog=335,319 Vars=86,328 Free=37,236 Stack=124 Undefined=200,704 Slot=648K
PAGE=&8F00 TOP=&5ACD7 LOMEM=&5ACD8 END=&6FE10 r13=&78F84 HIMEM=&79000 MEMLIMIT=&AA000

Address &FC15EDA4 in Module   WindowManager       @ &FC14D608 + &1179C

Register dump (at &2001BC30) is:
pc  = &FC15EDA4  Flags=&00000113=nzcv if  Mode=SVC 32 bit
r0  = &20002B24 : $+.  :  536881956 => &00000287 : ‡... : 647
r1  = &00000000 : .... :          0
r2  = &00000000 : .... :          0
r3  = &00000000 : .... :          0
r4  = &FFFFFFFF : .... : 4294967295
r5  = &00000000 : .... :          0
r6  = &00000000 : .... :          0
r7  = &00000000 : .... :          0
r8  = &00000000 : .... :          0
r9  = &00000000 : .... :          0
r10 = &20002B23 : #+.  :  536881955
r11 = &2001E394 : “ã.  :  536994708 => &FFFFFFFF : .... : 4294967295
r12 = &2001DF54 : Tß.  :  536993620 => &0700E135 : 5á.. : 117498165
r13 = &FA207F4C : L. ú : 4196433740 => &00000000 : .... : 0
r14 = &FC15EBD8 : Øë.ü : 4229295064

Code around address is:
FC15ED6C : .‘Yâ : E2599001 : SUBS    R9,R9,#1
FC15ED70 : .... : 0A000003 : BEQ     &FC15ED84
FC15ED74 : .à‰â : E28EE001 : ADD     R14,R14,#1
FC15ED78 : ..Wá : E157000E : CMP     R7,R14
FC15ED7C : ÷ÿÿ. : 1AFFFFF7 : BNE     &FC15ED60
FC15ED80 : .‡½è : E8BD8700 : LDMIA   R13!,{R8-R10,PC}
FC15ED84 : .p á : E1A0700E : MOV     R7,R14
FC15ED88 : .‡½è : E8BD8700 : LDMIA   R13!,{R8-R10,PC}
FC15ED8C : ..pã : E3700001 : CMN     R0,#1
FC15ED90 : .ð . : 01A0F00E : MOVEQ   PC,R14
FC15ED94 : .D-é : E92D4407 : STMDB   R13!,{R0-R2,R10,R14}
FC15ED98 : . @â : E240A001 : SUB     R10,R0,#1
FC15ED9C : .àŒå : E59AE01C : LDR     R14,[R10,#28]
FC15EDA0 : ..~ã : E37E0001 : CMN     R14,#1
FC15EDA4 < .✘½. : 08BD8407 : LDMEQIA R13!,{R0-R2,R10,PC}
FC15EDA8 : .  ã : E3A02000 : MOV     R2,#0
FC15EDAC : .. ã : E3A01000 : MOV     R1,#0
FC15EDB0 : .. á : E1A0000E : MOV     R0,R14
FC15EDB4 : .ààã : E3E0E000 : MVN     R14,#0
FC15EDB8 : ŠɌ : E58CE4AC : STR     R14,[R12,#1196]
FC15EDBC : Áøÿë : EBFFF8C1 : BL      &FC15D0C8
FC15EDC0 : .✘½è : E8BD8407 : LDMIA   R13!,{R0-R2,R10,PC}
FC15EDC4 : .H-é : E92D4807 : STMDB   R13!,{R0-R2,R11,R14}
FC15EDC8 : .àŒå : E59AE01C : LDR     R14,[R10,#28]

I can see nothing wrong with my parameters to SetCaretPosition, although I have yet to verify that the window is a valid one.
Note that there were two calls to SetCaretPosition – the first one worked, and the second failed.

I have had a look at the CnP Wimp changes … and there are hundreds of lines dealing with setting caret position. I cannot see where the code above is in the source, so I have come to the limits of my debugging for the moment.

Currently Organizer v2.28a (and probably earlier versions) will not run on RO5.27 (15 Dec 2019).
If other apps suffer the same problem, it will add to the clues for diagnosis.
If no other apps are affected, then perhaps Organizer is doing something that did ‘work’ but no longer does.

I tried my luck, on the Titanium, with a simple test app that on opening its window gains the input focus and puts the caret part way down the string in a writable icon. It does not explode with the new copy and paste Wimp.

*fx0
RISC OS 5.27 (15 Dec 2019)
*help WindowManager
==> Help on keyword WindowManager
Module is: Window Manager  5.65 (14 Dec 2019)

Select click on iconbar icon.

   WHEN 4
    PROCwimp_open(main%)
    SYS"Wimp_SetCaretPosition",main%,1,0,0,-1,10

Obviously there is a problem somewhere/somehow. There might be more to this, or my test isn’t valid.

I’d suspect the changes in s/wimp05 starting at line 44:

      [ CnP
        ; if we're called with R5=-1 then R4,R5 are calculated from R0-R3
        ; however, R4 is undefined on entry so could be anything.
        ; Internally we'd like to be able to use the call to put a ghost caret
        ; to a mouse click...
        ; we're doing the call by a SWI now, so need a way to get ghost caret calculations
        ; add R5=-2 for this purpose - calculate ghost caret details from x/y coords
        ; R4 *must* now be a valid flag set
        CMP     R5,#-2
        MOVEQ   R5,#-1
      ]

        BL      int_set_caret_position

R4 must be set to a valid flag set but are actually left undefined if R5 = -1.
Also curious are the already existing lines above these ones which manipulates some bits of R4, though according to the comments it can be undefined.

Now checking the SWI doc, it says that either R4 is either caret flags or -1 if no flags. This means that passing -1 on entry will result in an invalid set of flags.

@David: You beat me to it with a test app! Could you try SYS "XWimp_SetCaretPosition",main%,-1,0,0,-1,0 to mimic my failing parameters?

@André: I did see those comments, and tried setting r4 to 40, but it had no effect. But I am not sure I understand the ramifications of all the register inter-dependancies, particularly as they seem to vary depending whether it is the original PRM, the SH manual, the comments above, or the ROOL wiki. It may be that Organizer is using a combination which was illegal but worked … until now.

Ahah! I have just noticed that the failing instruction was
LDR R14,[R10,#28]
and r10 =&20001C23 which is not word aligned.
As an experiment, I changed my Pi from from Strict (alignment exceptions on) to Fast (alignment exceptions off) and the program started normally.
It is not suprising that r10 is not word aligned, as the previous instruction is SUB R10,R0,#1

Could you try SYS "XWimp_SetCaretPosition",main%,-1,0,0,-1,0 to mimic my failing parameters?

That does not crash here.

@David: Have you got alignment exceptions on or off?

@David: Have you got alignment exceptions on or off?

alignment exceptions are on.

I have found the code that aborted in CnPCaret lines 708 onwards…

check_unshaded_selection_window
        ; if the window losing the input focus has a selection, redraw it to ensure it becomes unshaded
        CMP     R0,#nullptr
        MOVEQ   PC,R14
        Push    "R0-R2,R10,R14"
        Abs     R10,R0
        LDR     R14,[handle,#w_seldata+wselicon]
        CMP     R14,#nullptr
        Pull    "R0-R2,R10,PC",EQ       ; nothing to do here

Hi folks. It’s my bit of code causing you grief at the moment. Sorry for the inconvenience – I’m trying to track down the bug!

On entry to check_unshaded_selection_window, handle is supposed to have 1 subtracted as R0 is a window handle on entry rather than an address. However, this means that there’s an invalid window handle stored for some reason at a previous time. That’s why most of the time the SetCaretPosition calls are succeeding OK. I just need to find how/why/when we get an invalid handle in there and then fix that…

Martin, did you get the email I sent you this morning to a blueyonder address from the Organizer website? It may have gone to junk. In short, I was hoping to borrow a copy of Organizer that breaks the Wimp and if there’s a particular user/mouse sequence that reliably faults?

Thanks

Glad you are on the track of the bug! The Blueyonder address is not mine – it is Nigel’s. In case he is not around to pass it on to me, at [address removed]

Further testing here has shown than previously an Error=&287 “Input focus window not found” was returned for this call (and ignored), and Andy is aware.

I’m happy to report that Organizer’s clock display still works, and that one can access the diary page OK as well. It’s things more complicated than that which fall over!

RPi 2 original version – latest ROM.

Hopefully it’s only a temporary glitch for a day or so!

My former headteacher (yes, I mean Head Master) used to bemoan the use of “hopefully” in this sense – but he’s well-dead! Even more pedantic than I am!

Am I also becoming intolerant in my old-age? Probably!

At least it’s possible we all won’t have to upgrade Organizer instead of continuing using whatever incarnation we’re on currently! I was preparing to demand that Martin offer multiple version patches if t’were his “bad” (down wit da kids)!

My former headteacher (yes, I mean Head Master) used to bemoan the use of “hopefully” in this sense

Sorry to drag this temporarily off-topic. Self-confessed pedant, here. Is that because in your sentence it would be the glitch (or whatever the subject, “it” is referring to) that would be considered to be feeling hopeful? I must admit, I’m fascinated! :)

I have almost certainly used “hopefully” in the same way, and I’m not sure what’s wrong with it. But my Kiwi brain twitches at seeing a Z in “Organiser”, so don’t ask me :)

my Kiwi brain twitches at seeing a Z in “Organiser”, so don’t ask me

http://clive.semmens.org.uk/Opinion/Ize.html

Bravo Clive! I learned to spell from the O.E.D. so I’m mostly with you on that, although you may catch the occasional ‘s’ creeping in now and again.

Organizer may ‘work’ on latest ROM, if Alignment Exceptions are turned off.

It’s things more complicated than that which fall over!

I have not heard of any other problems – can you PM me with details?

The spelling of Organizer makes me wince a little … it was called Organiser until v1.31 (16th March 1998) when Chris changed it to shareware. I think the name change was to avoid a clash with something else, but my memory is a little vague.

The spelling of Organizer makes me wince a little

It really shouldn’t. The S is a modern aberration, much encouraged by Microsoft.

Interestingly, that great authority the King James bible has “baptize”, but no “organize” or “organise”.

Shakespeare uses neither, though he does use that supposed Americanism “gotten” 6 times! Language of the Pilgrim Fathers!

Having had my secondary education ’58 to ’65, I have always used “ise”, imagining “ize” was an Americanism, but it is amazing how one can be so wrong over so many years!

I have stuck faithfully with “yoghurt” despite pressure to change!

I quoted “Organizer”, which gave rise to this diversion, because that’s what it’s now called – whether we like it or not!

I unfortunately can’t lay my hands on my Pocket Oxford Dictionary bought in 1958 and kept for sentimental reasons – it has the method for making nitrogen tri-iodide scrawled in the notes section at the back! If I find it I will complete this post in “Aldershot”, where it really belongs.

I’m sure Clive is grammatically right, but MicroSoft has never influenced me in any way whatsoever and never will!

On topic, I’m really pleased that it may be the revised Window Manager which may be at fault, as I really miss my Organizer (sic)!

I’m sure Clive is grammatically right

This ain’t grammar, it’s spelling – and in modern English, it’s still optional, as it has been for at least seventy years, albeit moving from mainly Z to mainly S over that period.

8~)

And yes, any further discussion of this really oughta be in Aldershot (Hampshire).