Unexpected abort in Utility module
Pages: 1 2
Alan Adams (2486) 1149 posts |
A program which has been running regularly for over a year has just started aborting at the first WimpPollIdle. The progfram hasn’t changed, and it sometimes does work. It’s written in BASIC. RISC OS version is 5.29, 22-Dec-22. The abort details are: Reporter 2.72 (15 Aug 2020) List Thu 5th Oct 2023 15:40 ~pollmask%=&40F830 ~wimpblock%=&23B10 ~then%=&2FABA ~reason% Memory: Prog=20,798 Vars=122,520 Free=262,392 Stack=48 Undefined=0 Slot=400K
Reporter 2.72 (15 Aug 2020) Listed 82 lines |
Stuart Swales (8827) 1357 posts |
Offhand, without a modern memory map to hand, I’d say that it’s never encountered an address so close to the end of a page like &3B7EEFFC before. Reading beyond end of page of some dynamic area / heap? |
Alan Adams (2486) 1149 posts |
so the polling loop follows. The error occurs on the WimpPoll line. pollmask%= (1<<4) + (1<<5) + (1<<11) + (1<<12) + (1<<13) + (1<<14) + (1<<15) + (1<<22) REPEAT END |
Rick Murray (539) 13840 posts |
Does a debugger annotated dump provide any further info? |
Stuart Swales (8827) 1357 posts |
Julie wrote a logical memory map dumper – why not try that to see where the block R5 points to is located? |
Graeme (8815) 106 posts |
Your pollmask has bit 22 set to say you have a pollword in R3 but you are not setting the pollword. BASIC will set it to zero. It doesn’t look like your program is using pollwords because you mask them out by setting bit 13 and have no WHEN 13 statement. Is it possible the Wimp is trying to load from memory address zero and being blocked? It doesn’t seem to match the assembler output so it may not be the issue. |
Alan Adams (2486) 1149 posts |
So I’ve removed the bit 22 from the pollmask – still mostly fails. It does occasionally work, which is worrying, as that suggests it’s working by accident, picking up some random value from somewhere. |
Alan Adams (2486) 1149 posts |
I tried *memory 3B7EEFFC, which returned abort on data transfer at &FC1EF6CC, which is similar to, but not the same as, the abort from the program. Wimp_Poll only uses R0 to R3, so that’s not where R5 gets set. Before the first Wimp_poll there are a number of calls to IIC_Control – could they be leaving something in R5? |
Stuart Swales (8827) 1357 posts |
If you can identify the block containing 3B7EEFFC (the owner will vary no doubt by platform / usage) it might give a hint as to what’s accessing it. |
Rick Murray (539) 13840 posts |
I’m not at the computer so my memory may be faulty, but I think there’s also the syntax:
to perform the access in supervisor mode, in case it’s something the OS can get to buy users can’t. Worth a try…
If you’re using BASIC, it’s a sanitised environment. That is to say, registers not explicitly set will be set to zero. See if Debugger can help → https://www.riscosopen.org/wiki/documentation/show/Debugger%20Annotated%20Exception%20Dumps |
Stuart Swales (8827) 1357 posts |
Lo and behold it is sprite plotting code that’s faulting. See PutSprite in vdugrafg: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/vdu/vdugrafg#L1187 probably https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/blob/master/s/vdu/vdugrafg#L1325 2p says that it’s down to the combination of sprite files loaded at that moment. Please tell me the address is the Wimp Sprite Pool… |
Rick Murray (539) 13840 posts |
Why would Wimp Poll be involving that? |
Alan Adams (2486) 1149 posts |
The platform is an rPi 3B+; I’m using the IIC interface to talk to an IIC-to-one-wire adapter. Prior to the Wimp_Poll I interrogate the possible adapter addresses on the IIC bus (there are 4 possible values). However removing those calls to IIC made no difference. Could that address be for the GPIO hardware? |
Stuart Swales (8827) 1357 posts |
It isn’t, it’s redrawing something else and wandering off the end of the sprite data, which has somehow got to the end of a page with no page beyond that one.
Your are thinking of the P option perhaps, to access Physical addresses. The Debugger IS in supervisor mode. |
Alan Adams (2486) 1149 posts |
I have now managed to get a debugger dump. Does it mean anything?
R15 = fc038858 = UtilityModule +182d4 SVC stack: R14_usr = 201d7388 = Reporter +b14 = Poll +a4 USR stack: End of dump |
Stuart Swales (8827) 1357 posts |
SWI XOS_SpriteOp ;-) |
Alan Adams (2486) 1149 posts |
Called from Wimp_PollIdle? |
Stuart Swales (8827) 1357 posts |
Yeah, why not? You’ve yielded control to the Window Manager, and it’s off doing other things. |
Alan Adams (2486) 1149 posts |
So I’ve commented out all the IIC code that was occurring before the first Wimp_Poll. The error still occurs on the rPi. I’ve tried running it on the ARMX6, where it successfully opens the window and polls. As it hasen’t found any hardware addresses (code commented out, hardware not present) it can’t do more. The original code works on a different rPi 3B+, including successfully getting data over the one-wire bus. That’s running the same OS version – in fact it’s running a clone of the same SD card. Uh! |
Stuart Swales (8827) 1357 posts |
My Pi is a bit buried at the mo – could you try seeing what running the memory map dumper outputs? https://www.riscosopen.co.uk/forum/forums/11/topics/15501 I’m 99% sure its the Wimp Sprite Pool. Are you IconSprites-ing anything when running your program each time?
100% clone? ;-) Does it fail on the other system when run a sufficient number of times? Swap cards over? |
Alan Adams (2486) 1149 posts |
I’ve now tried Julie’s memorymap program. The address 3b7eeffc appears to be in the wimp sprite pool. |
Stuart Swales (8827) 1357 posts |
Aha. Can you *Save the Wimp Sprite Pool out? We could have a grok to see if the last sprite in there is invalid in some way to provoke the VDU driver fault. |
Alan Adams (2486) 1149 posts |
The program fails on the origonal pi from a cold start. It does nothing with the sprite pool. There are no sprites used in its templates. The fault moves with the SD card. HOWEVER: So the question now is “What is going wrong with the sprite handling?” I’ve replaced the sprites file in question with one from a machine that doesn’t have the problem. No change. This is not really surprising as both the date and the size were identical. Instead of pinning the application, I changed the startup to run a program from that set. That program loads a different icon from the same sprite file to the iconbar. Doing that causes the problem to occur. So remove references to the sprite file and reboot. The !Run files are identical between the two SD cards, yet only one behaves itself. |
Alan Adams (2486) 1149 posts |
How would I do that please? I’ve tried *save spritepool 3b603000 3c502fff and got “no readable memory at this address”. This was done on the machine that doesn’t have the problem. The addresses and error message are the same on the problem machine (or rasther SD card). That odd address in R5 is in the wimp sprite pool, not the system sprites, so that’s the area I’m trying to save. |
Rick Murray (539) 13840 posts |
Wimp_ReadSysInfo 16 will give the low and high priority sprite areas in R0 and R1 respectively. Use OS_SpriteOp to save ’em. Off the top of my head: SYS "Wimp_ReadSysInfo", 16 TO low%, high% SYS "OS_SpriteOp", 12+256, low%, "$.wimpslow" SYS "OS_SpriteOp", 12+256, high%, "$.wimpshigh" |
Pages: 1 2