!Paint crash

When clicking and dragging the sliders in paint it will crash with “Abort on Data Transfer at &FC019528”. (The exact address varies but always begins &FC……)

Anyone can reproduce the effect by opening any sprite in Paint and tring Paint > Edit Palette and keep your mouse pointer on a slider bar, dragging it backwards and forwards (or up or down).

Admittedly you might have to do that for a while before the crash happens in this contrived example but when in the middle of editing a sprite and this happens, it is very annoying to lose work.

As far as I am aware it affects all versions of RISC OS 5 on the Raspberry Pi and Beagleboard although it may have been fixed in the very latest release?
thanks,
Richard.

Actually, in RC8 it is perhaps worse:

“Internal error, no stack for trap handler:
Internal error: abort on data transfer at &FC3762DC:registers at 202DF540”

I’m pretty sure this has happened to me in the past — but in Draw.

Perhaps there is a common link with pointers/icons/slider bars.

Did you raise a new ticket in the “Bugs” section, Richard?

Chris

Any chance of this being fixed chaps at ROOL? It’s still a problem in RISC OS 5.20 in Paint and Draw.
Thanks
Chris.

Still broken on Raspberry Pi, RISC OS 5.21 (01 Oct 2013), Paint 2.15 (07-Aug-13)

Error from Paint: Internal error: abort on data transfer at &FC0195B4
*where
Address FC0195B4 is not in any module

Ticket #339 refers.

I thought this bug was being preserved for old times sake, as we’ve all grown so familiar with it? ;-p

for old times sake

I found a stand alone !Paint 2.00 (13-Nov-07) on my Iyonix and that has the same bug.

(Edit. When run on the Raspberry Pi.)

Admittedly you might have to do that for a while before the crash happens…

How long must I take?
I use !Paint from my a9home on Beagle, Panda, Pandora, RPi … no crash.

http://youtu.be/i8xCC3Z8p5s

Or http://www.youtube.com/watch?v=i8xCC3Z8p5s if you prefer the old fashioned style.

Its my self-built early August OS on a 256Mb Pi.

If this problem can be repeated with regularity, please describe all of the steps from boot; do not forget to describe the screen mode, which slider, how long, etc.
If a specific sprite does this, provide a link to it.
The colour editor can be opened stand-alone or hung off a menu. Which?
Is the screen mode a factor? Does it happen in, say, 1024×768? 32K cols?

Suffice to say… “Doesn’t happen for me” which is zero use in beginning to track down the problem!

My specs: Pi, 256Mb. 1024×976 (IIRC) 16M col mode (it’s an HDMI→VGA adaptor).

Dear Rick, the error is simple to produce. Boot your machine as normal. Load in the !Paint program from the Apps folder (on the Icon Bar.) Select click on Paint’s icon. Go with the settings chosen by Paint, the Name is newsprite, width 1080 and depth 1920 here, No palette. Click OK. The “newsprite” Colours window should pop up. Ensure CMYK radio is selected. Click and hold on any of the four slider bars, it takes less than four seconds for Paint to crash. Richard.

Ah – CYMK. Nobody mentioned that yet. I’m guessing your mode is 16M colours and the sprite likewise?

I’ll try it tonight if I get back early enough.

Okay. It isn’t Paint. I feel fairly certain that I can say this as the CYMK trick caused Draw to fail, only instead of the abort, it complained it couldn’t load a message.

It seems fairly reliable that calling up the Colour Picker, switching to CYMK, setting the upper three sliders (CYM?) to zero, doing anything with the bottom (K?) slider will cause an abort or failure or some kind.

The SOLE exception to this is OvationPro, which while normally a very quick program, only seems to deliver events to the ColourPicker once per second, plus holding down a slider and not moving the pointer appears to do nothing at all (as opposed to the endless flickering updates performed by Paint etc). I wonder if Mr. Pilling has run into this problem and sussed a workaround?

At any rate, it seems to me that Paint is a casualty and the problem is in ColourPicker – though perhaps Paint could handle it slightly better, huh? ;-)

it seems to me that Paint is a casualty and the problem is in ColourPicker

It is not just ROOL’s !Paint, ROOL’s !Draw 1.24 and !Paint 2.56 from the A9home also give the same abort at &FC0195B4 when using the CMYK sliders.

No, the Paint bugs that always plagued me were related to the brush tool and selection – both redraw related and highly likely to be dangling pointers.

the Paint bugs that always plagued me were related to the brush tool and selection

Which bugs? Is there a bug report for them?

Evidence that it is ColourPicker:

Open a TaskWindow and enter the following:

DIM x% 36
x%!0 = 0
x%!4 = 0
x%!8 = 600
x%!12= &80000000
x%!16= &7FFFFFFF
x%!20= 600
x%!24= 0
x%!28= 0
x%!32= 0
SYS "ColourPicker_OpenDialogue", 0, x%

Run it. Then when the ColourPicker appears, use Alt-Break to kill the TaskWindow (or else things will appear to freeze up).

That done, you can use ColourPicker, so switch to CYMK mode and ensure Cyan, Magenta, and Yellow are all at zero.

Position your pointer over the Black bar (anywhere is fine) and press and hold the Select key.

In around a second and a half, you will see an error. Probably about TaskWindow. If you describe, you will see “Internal error: abort on data transfer at &FCxxxxxx”.

Close the TaskWindow to make ColourPicker go away (but you can get it to crash repeatedly… ;-) ).

Fired up rpcemu with OS 5.21 13-10-2013 only to find I could not reproduce the CMYK sliders bug, the bug which appears all too readily on the Raspberry Pi running a ROM of the same date. I could not spot any obvious difference other than the total amount of RAM, 448MB for the Pi and 128MB for rpcemu. Blew the dust off of the Iyonix running OS5.20 and that does not show the bug either, with 128MB RAM. Increased rpcemu’s RAM to the maximum of 256MB and still no bug. Reduced the Pi’s RAM to to 256MB, with gnu_mem=256 and the bug is still very present.

CMYK sliders now fixed

Many thanks.