Possible buffer overrun in WaveSynth module

I’m seeing a random crash within WaveSynth, in the Finished code (line 739):

LDMIA R13!,{R9}
MOV R2,#0
STMIB R9,{R2-R8}
MOV R0,#0
STRB R0,[R12],R11
STRB R0,[R12],R11
STRB R0,[R12],R11 << crashes here
STRB R0,[R12],R11
CMP R12,R10

Registers at the time of the crash are:
R0=00000000 R1=7F000000 R2=00000000
R3=00000000 R4=FFFFFFFF R5=00000000
R6=00000000 R7=00000000 R8=00000060
R9=FAFF4100 R10=FAFF8000 R11=00000004
R12=FAFF8000 R13=FA101F8C R14=FC2DCC80
R15=20050E58 PSR=80000012


Could it be overrunning the sound buffer under certain conditions?

Could it be overrunning the sound buffer under certain conditions?

Yeah, it looks like it will overflow the buffer if the sound finishes right at the end of the buffer. I’ve just checked in a fix, so everything should be OK come tomorrow’s ROMs.

Thanks Jeffrey, I’ve been trying to create a repro all week, to no avail! I’ll check the new ROM build tonight and confirm if it’s resolved the issue.

EDIT: Looks like 4.11 didn’t make it into the build, so I’ll test tomorrow.

The code changes are now in the ROM, however it crashes in the same place:

LDR R9,[R13],#4
MOV R2,#0
STMIB R9,{R2-R8}
B &20051734
STRB R2,[R12],R11
STRB R2,[R12],R11
STRB R2,[R12],R11 << crashes here
STRB R2,[R12],R11
CMP R12,R10

Registers at the time of the crash are:

R0=200517A4 R1=7F000000 R2=00000000 R3=00011111 R4=FFFFFFFF R5=00000000 R6=00000000 R7=00000000 R8=00000060 R9=FAFF4100 R10=FAFF8000 R11=00000004 R12=FAFF8000 R13=FA101F8C R14=FC2D7330 R15=20051734 PSR=80000012

EDIT: At the time it crashes, R12=FAFF7E78 / FAFF7E9C on entry so the problem may be outside of WaveSynth and possibly in SoundDMA or SoundChannels?

EDIT2: Repro steps from BASIC

SYS “Sound_Configure”,0,0,0,0,0 TO A%,B%,C%,D%,E%
SYS “Sound_Configure”,4,1024,C%,D%,E%

Hold END to repeatedly generate a beep.

EDIT: At the time it crashes, R12=FAFF7E78 / FAFF7E9C on entry so the problem may be outside of WaveSynth and possibly in SoundDMA or SoundChannels?

On entry to where – Finished, or WaveSynth’s buffer fill code? If that’s the value on entry to Finished then it’s fine (apart from the obvious crash).

Try as I might, I can’t get R12 to be anywhere near that when playing sounds in BASIC, it’s always below FAFF7280

Yes, the location of the buffer will shift around a bit depending on how many channels are in use (1 or 2 = start of page, 4 or 8 = end of page).

Anyway, after taking a second look at the code I’ve spotted what the problem is. WaveSynth normally outputs samples 4 at a time (which is fine, all current versions of SoundDMA ensure the per-channel buffer size is a multiple of 4). But Finished can get called from any point, including when halfway through a 4 sample block. So I’ve now checked in a new version which simply checks for the end of the buffer before each write within Finished. I would have spotted that sooner, but thought your ‘crashes here’ marker hadn’t taken into account the 8 byte PC offset. D’oh!

EDIT2: Repro steps from BASIC

SYS “Sound_Configure”,0,0,0,0,0 TO A%,B%,C%,D%,E%
SYS “Sound_Configure”,4,1024,C%,D%,E%

Hold END to repeatedly generate a beep.

Yep, I can confirm that the new version fixes that.

We got there in the end :)

I noticed SoundChannels has the same 4 byte fill loop in Level1FlushLoop (line 1672), it may suffer the same issue so you may want to check it.

but thought your ‘crashes here’ marker hadn’t taken into account the 8 byte PC offset. D’oh!

Someone needs to change the Debugger so it shows the correct instruction to save this constantly being a source of confusion!

I noticed SoundChannels has the same 4 byte fill loop in Level1FlushLoop (line 1672), it may suffer the same issue so you may want to check it.

I believe that code only runs when the entire buffer needs flushing, so it should be safe.

Someone needs to change the Debugger so it shows the correct instruction to save this constantly being a source of confusion!

What confusion? The Debugger is telling the truth – at the point of the failure, the PC was at that location, two instructions ahead of the instruction actually being executed.

We perhaps ought to be glad that the ARM is simplifying its world view and that, generally, PC is two words ahead even though modern ARMs are horrendously more complicated than the ARM2! The Pi’s pipeline is eight stages. The Cortex-A8 is 13 stage and can execute two things at once if there are no interdependencies. Don’t ask about the Cortex-A15. Complex much.

The PC isn’t the source of confusion, it’s the arrow that indicates which instruction crashed that’s confusing.