FYEO2 bug list

This document lists the 'known' bugs in the current version of FYEO2, along with 'thoughts' and workarounds (as applicable).

If you have anything to add, please email me.


#01 Crashes with multiple windows open (REPAIRED)

Reported by Rick Murray, 2004/02/28

Synopsis:    If you view a number of images concurrently (usually five),
             FYEO2 will crash with two errors (when JPEG decoding, at least).
             The first will be "Unexpected EOF in JPEG file", followed by an
             internal error (abort on data transfer).

Proposition: If you quickly toggle the image windows full size, the one that
             will fail contains a few rows of pixels, usually near the bottom
             of the image. When decoding reaches this point - boom!
             This points to some memory being incorrectly allocated.

Historical:  A similar problem existed with the older version 2.05 though not
             in the same form; however after ~5 images it would complain
             about running out of WimpSlot, and crash.

Solution:    Given the 'historical' message, I have increased the WimpSlot to
             320K (from 256K). I do not consider this bug to be fully 'fixed'
             as whatever memory allocator is failing SHOULD detect when the
             application runs out on memory...
             ...I suspect that this is related to the intermixed calls to
             malloc() while flex allocations are active, hence clashes over
             who belongs where.
             However I have just viewed 108 JPEGs (from my website directory)
             using the same FYEO2 and no corruption or crashes...


#02 Dither menu error

Reported by Rick Murray, 2004/03/04

Synopsis:    If you open the iconbar menu, then the "Dithering" menu will
             behave like the iconbar menu (which can be pretty weird to see).

Proposition: I think this is due to a tiny difference between the RISC_OSLib
             that was originally used, and the 26/32 neutral one, which
             doesn't appear to export one of it's internal variables that
             FYEO2 uses.

Workaround:  Open the preferences window by clicking SELECT on the iconbar
             icon; DO NOT use the iconbar menu, except to Quit (unless you
             will not need to alter the dithering).


#03 4bpp BMP decode error

Reported by Rick Murray, 2004/03/05

Synopsis:    Some 4bpp BMPs fail to decode, the output gets all screwed up.

Proposition: Most likely my maths in the bit shifting. I will look into this,
             obviously, and I would appreciate SMALL examples that exhibit
             this behaviour.
             The same goes for 1bpp, 8bpp, and 24bpp; though I'm fairly
             confident that 8bpp and 24bpp work 'just fine'.

Workaround:  None. If you can send me SMALL examples (say, under 12K unless
             otherwise arranged with me), then I'll have more to go on.


#04 Disc read failure (during JPEG) causes crash

Reported by Rick Murray, 2004/03/06

Synopsis:    When reading a JPEG on a corrupted disc, as the corruption
             is encountered, FYEO2 fails with the error:
               Internal error, no stack for trap handler:
               Internal error, abort on data transfer at &xxxxxxxx,
               pc = xxxxxxxx: registers at xxxxxxxx.

Proposition: I tried inserting specific signal handling, and also tried to
             trap the file read where the error occurs; neither had any
             I suspect that this goes back to something earlier (and possibly
             deep within the JPEG code). A truncated JPEG does not cause this
             problem to occur (an EOF is not an error, just a condition),
             while an actual disc read error (an OS error) is likely to cause
             things to be handled differently.
             It is also interesting to see the double error message...

Workaround:  None. Given that this error occurs due to a corrupted JPEG file,
             I suspect you'll have more important things to worry about. :-(

#04 "Bad parameters to get_mode_from_specs" on RISC OS 5.05

Reported by James Robinson, 2004/03/10

Synopsis:    FYEO2 fails to render, aborting with the error message:
                "Bad parameters to get_mode_from_specs"

Proposition: Possibly an incompatibility with calls to work out the screen
             dimensions, which are not compatible with the non-VIDC
             hardware in the Iyonix (James has an Nvidia GeForce 2).
             FYEO2, currently, only handles a 'standard' selection of DPI and BPP
             types, and it may be that RISC OS 5 offers more that FYEO2 simply
             does not recognise.

             Can people with FYEO2 and an Iyonix please run the program below and
             tell me what the results are (unless every Iyonix has the Nvidia
             GeForce 2 installed...?).

                REM >Get mode dimensions

                SYS &35, -1, 4 TO ,, xeig%
                SYS &35, -1, 5 TO ,, yeig%
                SYS &35, -1, 9 TO ,, bpp%

                PRINT "Xdpi = " + STR$(180 / (1 << xeig%))
                PRINT "Ydpi = " + STR$(180 / (1 << yeig%))
                PRINT "BPP  = " + STR$(1 << bpp%)


Workaround:  Switch off "Use current mode" in the output options,
             and tell FYEO2 to use a specific BPP/DPI combination.


Return to FYEO2 index

Copyright © 2004 Richard Murray