Ticket #475 (Fixed)Tue Nov 05 01:32:42 UTC 2019
SpriteExtend can cause catastrophic failure when attempting to plot certain JPEG files
| Reported by: | Christopher Martin (1504) | Severity: | Critical |
| Part: | RISC OS: Module | Release: | |
| Milestone: | Status | Fixed |
Details by Christopher Martin (1504):
I have a JPEG file (which came from a downloaded PDF being API documentation for another system, if that matters). I would attach the JPEG here with a mini app to demonstrate the fault, but I can’t see how to attach files to a bug report. Attempts to plot the JPEG using JPEG_PlotFileScaled cause SpriteExtend to abort on data transfer, sometimes in a catastrophic way that brings down the machine with a chain of aborts. Apps which use SpriteExtend die in a variety of ways when asked to load the JPEG in question. On an Iyonix running RISC OS 5.27 softloaded, !Paint crashed the machine on loading the JPEG. RISC OS 5.24’s !Paint on the same machine also died albeit less catastrophically. I am certain that it is the SpriteExtend module which is failing to handle the JPEG in question in a sensible manner because I have tested this theory with a one-line BASIC program. Using the X form of the SWI (XJPEG_PlotFileScaled) does not appear to make any difference.
Changelog:
Modified by Christopher Martin (1504) Tue, November 05 2019 - 01:36:31 GMT
Here is the JPEG in question:
Content-Type: RISC OS; charset=US-ASCII; name=002.jpg,c85
Content-transfer-encoding: base64
/9j/4AAQSkZJRgABAQEAAAAAAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQE
BQoHBwYIDAoMDAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/
2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQU
FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCAACAsEDASIAAhEBAxEB/8QA
HwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF
BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkK
FhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1
dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG
x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEB
AQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAEC
AxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRom
JygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOE
hYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU
1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9NaKKKACi
iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK
KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoooo
AKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA
ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA//Z
Modified by Sprow (202) Wed, November 06 2019 - 07:41:26 GMT
- Attachment added: decoded.jpg
Just to check it decoded OK, is it a 705×2 JPEG which is very light grey?
Modified by Sprow (202) Sat, November 09 2019 - 18:29:38 GMT
A bit more fiddling locally, the issue is somewhere in romerge.c when trying to plot things less than an MCU tall (so 16 pixels for 2×2 sampling). But it’s not clear cut: if I have a pile of test images of heights 1-16, plotting them backwards (16 down to 1) instead of forwards (1 to 16) seems to work.
Modified by Sprow (202) Sun, February 09 2020 - 12:18:43 GMT
> But it’s not clear cut: if I have a pile of test images of heights 1-16, plotting
> them backwards (16 down to 1) instead of forwards (1 to 16) seems to work.
That turned out to be a red herring: the images were all uniform colour fills so the check in rojpeg.c “Look to see if this is precisely the same JPEG file as last time” was concluding the 2 pixel high image was the same as the 1 pixel high one and using the cached tables. However, when coming to plot the image and asking for scan line 2 hit the assert(ycoord >= 0).
Modified by Sprow (202) Sun, February 16 2020 - 17:36:02 GMT
- Status changed from Open to Fixed
Fixed in SprExtend-1_84.
