Unexpected abort in Utility module

I’ll try that.

[Edit] It produces two sprite files, each containing a lot of sprites.

They can be downloaded from https://adamshome.org.uk/RiscOS/Sprites/index.html

Julie wrote

Hmm, there’s somebody I’ve not seen in a while…

There was a version of Syslog being worked on. I wonder how far that got.

So it seems that something involved in sprite processing is producing an abort.

I understand that once I issue a Wimp_Poll then the system is doing stuff outside my program control or context.

However I don’t understand why this happens every time my program does a Wimp_Poll, and why the abort affects my program. Why does my Wimp_Poll trigger sprite processing?

The only connection I can see is that my program has an iconbar icon, using the sprite called templogger in the wimpshigh sprite file.

Thanks Alan.

Does anything render the stopw sprite? That’s a 16M colour sprite with bit mask (and an odd width). VDU driver could be wandering off the end of that; the end of the last sprite in that sprite area is only 8 bytes before a page boundary (consider file length + 4 for the length in the area header that’s not present in the sprite file).

*save spritepool 3b603000 3c502fff

I think you had a missing trailing f there. Indeed, you don’t specify the last address to save, but that +1. Is the address of the wimp sprite pool different on the machine that works ;-)

Is the address of the wimp sprite pool different on the machine that works ;-)

The sprite pool and system sprite addresses are the same on the working and failing SD cards.

Does anything render the stopw sprite?

It is used in the application, but it’s not being used when the problem shows up. I can have a look at editing it. It’s one I created from a picture.

I suppose the difference between the working and non-working cards might be the number of sprites before that one, and hence its closeness to a page boundary.

[Edit]

I’ve changed its width from 41 to 40 pixels, and a quick test seems to show the problem as fixed. More tests needed before I’m sure.

If that is the problem, it looks to me like a bug in the sprite rendering code.

If that is the problem, it looks to me like a bug in the sprite rendering code.

For sure it is. Well, the sprite is reduced in size, so it might no longer be quite falling off the end anyway! But at least the offending sprite is captured for posterity, and the rendering code deserves some staring at.

I’ve been attempting some rendering here using that (maybe) ‘bad’ sprite. IconSprites a one-row 32-column 1-bit MODE 0 sprite for padding, then IconSprites stopw, which I have rendered full-size in a template window (using the copy in the wimp sprite pool, not loaded into WinEd). Then a BASIC prog to keep adding rows to the padding sprite (i.e. 4 bytes a time) until the ‘bad’ sprite is moved up in the wimp sprite pool to reach a desired alignment with respect to the containing last page. I cannot get it to fault here! Pi 4, with 03 Oct 23 ROM, 16M colour display.

I cannot get it to fault here! Pi 4, with 03 Oct 23 ROM.

I’ve now passed the critical weekend for these pi’s, so I could try using a more recent rom. However I’m not sure that doing that would reproduce the wimp pool layout that seems to trigger the problem.

I’ll keep a copy of the sprites file anyway, just in case it turns out to be useful for testing sometime.

TESTING

I reinstated a copy of the sprite file with the 49×41 pixel sprite.

The application with the faulty sprite is called !Slalom
The application that aborts is called !Templogger
Both iconsprite their own sprite files

If, after a clean boot, templogger is run it works.
If Slalom is then run, templogger still works.
If templogger is then quit and run again, it aborts.

If after a clean boot, slalom is run before templogger, templogger aborts
If after a clean boot, slalom is pinned to the desktop before templogger is run, templogger aborts

The last case is the one that confused me, as I was getting aborts without needing to run !Slalom.

With the corrected sprite file, templogger doesn’t abort.

I’ve also tried the render-after-align test using the templog sprite, and still doesn’t fail. Bah.

[Edit: It does seem from inspection of the VDU source that all the ‘fast, simple’ plotting code paths read one too many words, potentially going off the end of a page. How far back this went, I do not know! Sadly the RO2 kernel I have is missing the VDU dir.]

Just to be sure, I put the SD card into a different P 3B+, and got exactly the same behaviour.

The minimum required to cause templogger to fail, is to open a directory containing the !Slalom application.

If it helps anyone trying to find/fix the rendering problem, I don’t think there’s anything too personal on it, so I may be able to supply an image of the SD card.

THe problerm can be seen on a rpi3 b+ 2017, and an rpi3 v1.2 2015. Both are 1 GB devices.

It can also be demonstrated on a 512MB Pi 1B v1.12.

I don’t have a pi4 to test on.

read one too many words

I think there’s something to be said that this edge case is only turning up thirty six years later.

I think there’s something to be said that this edge case is only turning up thirty six years later.

Make that “only identified 36 years later”. The way it showed up, it only takes small changes in apparently unrelated things to make it go away. I suspect it’s been seen before, just not identified.

In this case, two SD cards, cloned from the same source, then used in different ways for a few weeks. One shows the problem, the other doesn’t. The two pieces of software that cause the problem to show up are identical between the discs, but other apps run at startup for example, are different, changing the contents of the wimp sprite pool.

Well, there’s a nice reproducible test case for ROOL to get their teeth into in https://www.riscosopen.org/tracker/tickets/618.

Thanks for persisting with testing, Alan; many might have been happy that they’d (temporarily!) fixed the problem.

I didn’t like the idea of “temporarily”. These things tend to bite back at the worst possible time.

Make that “only identified 36 years later”.

Maybe, maybe not. Jeffrey rewrote some sprite plotting routines to support more screen modes and IIRC did some optimizations for newer ARM versions.

Unsurprisingly fails on RISC OS 4 as well. It’s not one of the ones that I fixed.

On the other hand, works fine on RISC OS Pyromaniac.

charles@phonewave ~/projects/RO/pyromaniac (report-error-vdu-experiment↑1)> pyrodev --common --wx --gos
Supervisor

*basic
BASIC V version 1.36 © RISCOS Ltd

Starting with 1044732 bytes free

>MODE "X800 Y600 C16M"
>*dir putsprite
>*!Athimem
HIMEM was &108000
<Obey$Dir>.SpriteFile length &3C
HIMEM now &107FC0
*

Which is also unsurprising, as it avoids the whole code path by having it entirely implemented in Python.

If I were younger and more energetic, I’d knock up a small module that trapped SpriteV and watched for that call, and if the sprite requested ends on a potential page boundary, change the call to one of the PlotScaled or PlotTransformed calls that goes through a different code path. Actually if I were younger, I’d resurrect the SpriteOp module… but meh.

You are younger here than most, and as for energetic, don’t make me reach for that cattle prod!