Maestro crash

RPi good – Titanium crashes. Why the difference?

A search of built sources shows different versions of the SoundChannel modules, filenamed Sound1.

BCM2835.RiscOS.Sources.HWSupport.Sound.Sound1.rm.RPi.Sound1 Titanium.RiscOS.Sources.HWSupport.Sound.Sound1.rm.CortexA7.Sound1

That test is indeed simpler. I realised yesterday that *ChannelVoice would trigger the same problem, and it seems that it does not matter which voice is used.

After failing to see from the SoundChannel source what the problem was (I think it disappears into DMAstuff, so I gave up) I did some (laborious) comparisons of memory blocks. My conclusion is that it is a typical out-by-one bug. The memory block just before the overwrite is 2,144 long. As channels 1-7 get allocated, the last 7 words of that block are populated, probably with an RMA address. When channel 8 gets allocated, the first word of the next block (which was a length of x20) is overwritten with the 8th address. This is the error trapped by *ReportHeap, and it causes anything else that traverses the RMA heap to fail.

Why it only seems to affect the Titanium, I have no idea, but the clue must be in the different sources.
However I think we have enough evidence to raise a bug report, referring to this thread. I will do that. Edit: Done – ticket #505

Nice work!

Looks like a 24+ year old bug in StringLib & Percussion. They both work by copying their handler code to the RMA, and the handler code is directly followed by 8 words of data (1 word for the state of each channel the voice can be assigned to). But between the end of the code block (End_Of_Code) and the label which marks the start of the 8-word channel data (Instance0), a couple of extra words have snuck in, causing the handler code to access beyond the end of the allocated area if the voices are assigned to channels 7 or 8.

Presumably the bug’s remained hidden until now because on most systems the OS is adding two or more words of padding to the allocated block length (there will be some slight variation in handler code length on different platforms because a few years ago I changed the DivRem macro to use hardware divide where possible).

That reminds me a strange problem I did have a few months ago: things in predesk were ignored and some Meastro tunes crashed. A voice module loaded at startup was the problem. I have no idea why it was working for years and stopped working suddenly.

some Meastro tunes crashed.

Crashed in what way?
And on what machine, and OS version?
What was the voice module?

Crashed: Abort on data, etc.
Machine: Pi4 and ROS 5.28 (before: Pi3 and ROS 5.27)
Voice module: a specific one, generated with SoundCon.

Nota: the sound module worked, on some Pi1 and Pi2, with older versions of RISC OS.
It’s difficult to know when it began to crash, as I don’t use Maestro everyday.

https://www.riscosopen.org/forum/forums/3/topics/15236?page=1
https://www.riscosopen.org/forum/forums/4/topics/15247

@David: If you could send me the voice module, I could easily check if it was a symptom of the same problem.

@Chris.

Jeffrey’s fixes are in git, a locally built ROM including them has Maestro playing music on the Titanium.

Thanks David – great to hear. And thanks to Jeffrey for the speedy fix too.

Should be fixed in tomorrow’s ROMs (StringLib 1.20 & Percussion 1.19)

https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/Sound/Voices/StringLib/-/commit/b00b28ed27075372b2ddc587314a1245a2e35e13
https://gitlab.riscosopen.org/RiscOS/Sources/HWSupport/Sound/Voices/Percussion/-/commit/3ce6450302dd67fb3d1a8fc5afdc81ed49ca3535

Thanks for the heap dumps, Martin; that certainly saved some time on my end.

Thanks for the heap dumps

No problem … *ReportHeap has long been able to optionally list blocks and their contents. However, it is possibly a litle-known facility that it also always validates the heap structure, and it lists the affected area if there is an error. I added validation when wrestling with block overwrites in an application heap – and it proved its worth then, and in helping to identify the cause of this problem with the RMA heap.

I am glad they led you to the root cause … I was lost!