Ticket #582 (Fixed)Mon Jan 16 17:06:49 UTC 2023

It didn’t crash here on Draw 1.43. Can you try again with the latest rom?

Using OS5.29 19-Jan-23 I have seen the fault on Pi’s but not on the Titanium. After a lot of digging, whether the fault appears or not is disc image dependent, it does not appear with an unbooted desktop. I now have two disc images for the RPi400, one shows the fault, the other does not, but so far I not managed to narrow it down to something specific. In the faulty image Choices.Boot was deleted allowing a clean default set to be written on startup and that is fault free. I am out of time now but will, some time later, reinstate things hopefully to see what makes it fall over.

This is a bit weird but the cause of the issue here was the sprite pinboard backdrop file. It is a user size adjusted version of the Pi Abstract backdrop. A jpeg of the same image is fine and so far no other sprite file has been found to be problematic. The backdrop in question is attached.

Bug report from RPi400.

<pre>
*FX0
RISC OS 5.29 (19 Jan 2023)

*Help !Draw
==> Help on keyword !Draw
Module is: !Draw 1.44 (04 Jan 2023)

*Help SharedCLibrary
==> Help on keyword SharedCLibrary
Module is: C Library 6.16 (28 Dec 2022)

Error from Draw: Unrecoverable internal error (Internal error:
abort on data transfer at &FC18CCD8), must exit immediately

*where
Address &FC195AEC is at offset &00013A0C in module ‘SharedCLibrary’

*ShowRegs
Register dump (stored at &200032B0) is:
R0 = 00021000 R1 = 4A1E4337 R2 = 01010000 R3 = 00020E56
R4 = 00008E14 R5 = FC191D74 R6 = 00008E70 R7 = 20346C94
R8 = 00000000 R9 = 00008F04 R10 = 00008230 R11 = 00008E6C
R12 = 01010101 R13 = 00008E10 R14 = 80808080 R15 = FC195AEC
Mode USR32 flags set: nZCvqjggggeAift PSR = 60000110
*MemoryI PC-20 +40
FC195ACC : ..Q„ : E3510000 : CMP R1,#0
FC195AD0 : …. : 0A000010 : BEQ &FC195B18
FC195AD4 : …„ : E3100003 : TST R0,#3
FC195AD8 : ˙ˇˇ. : 1AFFFFFA : BNE &FC195AC8
FC195ADC : ∆. : E51FC620 : LDR R12,&FC1954C4
FC195AE0 : 儆· : E1A0E38C : MOV R14,R12,LSL #7
FC195AE4 : ..ê‰ : E4901004 : LDR R1,[R0],#4
FC195AE8 : . A‡ : E041200C : SUB R2,R1,R12
FC195AEC < . ¬· : E1C22001 : BIC R2,R2,R1
FC195AF0 : …· : E112000E : TST R2,R14
FC195AF4 : ˙ˇˇ. : 0AFFFFFA : BEQ &FC195AE4
FC195AF8 : ˇ..„ : E31100FF : TST R1,#&FF ; =“ˇ”
FC195AFC : ... : 02400003 : SUBEQ R0,R0,#3 FC195B00 : .... : 0A000004 : BEQ &FC195B18 FC195B04 : ˇ..„ : E3110CFF : TST R1,#&FF00 FC195B08 : ... : 02400002 : SUBEQ R0,R0,#2
*
</pre>

The bug can be reproduced on the Titanium.

The bug can also be reproduced on a new installation of the RISC OS Pi SD card image. The 1920×1013 Abstract and Octagons Sprite backdrop files show the issue. The other supplied variants do not. As the default backdrop is Octagons the potential for the fault is also present by default.

I couldn’t recreate this on a Titanium even with the Octagons sprite backdrop. But it did trigger on a Pi 2, so that’s enough to go on.

The function that’s aborting is strlen() in the C library, and the clue appears to be in that register dump that R0 is a multiple of a page. Grabbing Draw’s application slot with StrongEd shows the ‘Hello World’ text area right near the end, and after the text area is what looks like sprite data, and crucially…there are no zero bytes between the end of the text area and the end of the Wimp slot.

Turns out in draw_text_verifyTextArea() there’s a call to parse the font size which uses strtod() which is what’s calling strlen(). That’s what aborts when it doesn’t find a terminating 0 before falling off the end of the Wimp slot. More care needed.

The repro conditions did change, it did become more difficult to reproduce. The fault was replicated here on an RPi400 and the fix did fix it.

This issue has been around for ages, it could even be reproduced on OS4.39.

I found it easier to trigger when !Draw was built into a ROM. One loaded off disc ends up with the code + variables in the wimp slot (whereas when in ROM the code executes in place) so moved everything around or higher up and didn’t get unlucky with recycled pages as often to cause the crash.

Glad to here it’s fixed it for you – let’s see how it shuffles through review.

Fixed in !Draw 1.46