Sleuth3 misbehaving on a Pi

I’m using Sleuth3 on a Raspberry Pi (model B, RISC OS 5.21, 13-Sep-14). I’m getting persistent unrecoverable errors when attemping any processing (rotation, finding zones, OCR’ing) of previously scanned sprites: the full error message reads:
‘Unrecoverable error in run time system: Not enough memory, malloc failed, (heap overwritten)’.

Two oddities: the same Sleuth3 version has no problem processing identical sprite files when running under 5.20 on RPCEmu, and on the Pi, it /is/ possible to process a page as above, providing it has been scanned first as part of a continuous process – it is only when processing previously-scanned pages that the problem arises. AFAICS, the Sleuth3 versions running on RPCEmu and the Pi are identical – same files, same file sizes, same dates. Both versions create a scrap file in !Scrap.ScrapDirs when launched; the memory allocated to both in Application Tasks is the same: 1692K; moreover, the Model B Pi has twice as much installed RAM (512MB) as is available to RPCEmu. Do 5.20 and 5.21 differ in the way malloc (whatever that might be) is handled?

In short, I cannot see why the RPCEMu version works properly and the Pi version doesn’t. Any advice or help with this would be appreciated – it’s not a showstopper as I have RPCEmu to fall back on, but the Pi is my main RISC OS platform and I would like this useful app to work properly on it!

Not sure but RPCEmu is StrongARM, RPi not. Have you try other CPU settings via !Configure?

Good point. I’ve always run the Pi in ARMv5 compatibility mode. Sleuth’s !Boot file is dated May 1998 and the !Run file is dated May 2004 in my installation. I’ll try the other CPU options to see if that helps.

A other option should be aemulor.

On selecting ‘OCR’ with a sprite loaded into Sleuth, rotated and zoned:

Aemulor: same error as original.

CPU speed set to default (700MHz) from 900MHz: same error as original.

All other icon bar apps quit before running Sleuth: same error as original.

ARMv7 strict mode (‘ae’ on) and fast mode (‘ae’ off): both produced type 5 fatal errors.

Sleuth deleted and reinstalled from originally supplied ZIP: same error as original.

So, it beats me; just one of those RISC OS oddities, I suppose, ;-)

Is it the last Version of Sleuth? Was V3 the last? Not sure. I newer used Sleuth.
ArcEM with RISC OS 3.1? ;-) or try Chris Gransden Tesseract port.

Just to say: I tried Sleuth3 on the BB a long time ago now and could never get it to work. I might give it a go on the RPi to see what happens.

Is Sleuth 3 even 32bit compatible? It might be worth contacting David Bradforth to see if the source is available.

As far as I can tell, the latest version is 3.02 which was released in 2000 so is unlikely to be 32bit.

Yes, it is 32-bit. It runs fine on my Iyonix. The version I have is 3.09, no date, but it does have 2004 in the author field (c. APDL and ProAction software).

Edit: The !RunImage is dated 3 Jun 2004.

My version is 3.09 also, and, as mentioned earlier, runs fine on RPCEmu0.8.11/5.20. It does partially work on the Pi, i.e., you can scan and process a sprite as a continuous operation. The problem in my case arises when processing of previously scanned sprites is attempted.

There’s a couple of possible root causes I can think of, if it is Sleuth code related:

1. Alignment issues, although I’d expect putting the Pi in ARMv5 mode to resolve it
2. There’s still the odd non-32bit instruction
3. Its using an instruction where the behaviour has changed slightly over ARM revisions
4. Its calling SpriteOp’s where the behaviour has changed. If this is the case the latest Iyonix RO5.21 build should exhibit the problem

There’s also the possibility its an OS issue.

If someone would like to eMail me a copy and detail steps to reproduce the problem, I’m happy to take a look into it for you: jon at jaspp dot org dot uk

2. There’s still the odd non-32bit instruction

Drop the !RunImage file onto Armalyser and select “Statistics” only.
If that gives any 32 bit related errors then it’s time to use the disassembly or assembly options and text output for few clues.

3. Its using an instruction where the behaviour has changed slightly over ARM revisions

Picked up by Armalyser too I think.

There are two occurrences of ‘not 32bit safe’.

and

However, Armalyser is vintage 2007, so it could be missing some instructions that are not modern hardware friendly.

There are two occurrences of ‘not 32bit safe’

They could well be the cause of the problems. Have you tried changing them, you can probably just drop the ^ (change E8FD9FFF to E8BD9FFF and E8FD83F0 to E8BD83F0)

Armalyser is vintage 2007

I did eMail the author and enquire about the source last year, but didn’t hear anything back. If anyone knows the authors eMail address, perhaps send him a polite eMail, as it could do with a few tweaks.

Jon: I don’t have Armalyser, but can send you a zipped copy of Sleuth, a sample sprite and details how to reproduce the problem if you are willing to take a look. Email me at

george.greenfield/at/tiscali.co.uk

[replace /at/ with the usual symbol] and I’ll attach the necessary bits to the reply.

I’ve now taken a look (thanks for the Repro George), there are two issues:

1. Although it’s 32bit compatible, it’s not ARMv7 compatible. It looks like it’s making use of rotated loads as setting the Pi to ARMv5 appears to resolve the issue
2. As noted by Chris, there are two non-32bit instructions. Although these aren’t the root cause of the issue detailed above, they will cause issues at some point

Issue 1 would need a recompile to resolve, or simply run the Pi in ARMv5 mode (change under Configure\CPU)
Issue 2 can be resolved on v3.09 of the !RunImage, by creating an Obey file as below:

LOAD <Obey$Dir>.!RunImage 8000
MEMORYA 2B204 E8BD9FFF
MEMORYA 3C500 E8BD83F0
SAVE <Obey$Dir>.!RunImage 8000+4AAD8
SETTYPE <Obey$Dir>.!RunImage Absolute

Place this in the !Sleuth directory and run it, ensuring you take a backup of !RunImage first.

EDIT: Although the above fixes the crashing on my Pi, it’s not working for George. Could someone else please try Sleuth in ARMv7, then ARMv5 and see if it’s resolves the crashing when performing an OCR.

Update: Sleuth3 (with Jon’s mods incorporated) is now working on my Pi. As to the original problem, I suspect a USB card corruption issue, or maybe I had too many nested directories (8), since moving the directory containing the problem sprites to the card’s top level resulted in successful access by Sleuth. I’ve also updated the Pi’s OS version and firmware. The latter (as Jon has pointed out here
https://www.riscosopen.org/forum/forums/5/topics/3049
) involves reversal of the Red-Green channels and requires a Config/txt mod. It also seems to have reduced the Pi’s speed by about 5%, according to !Firebench – I have no idea why. Thanks anyway to Jon for his help, and to others for their comments!