Download problems

I am having problems with NetSurf (on RO 5.28 on a Rpi3B+). I have NetSurf 3.11 (Dev CI #5312). When I try to download anything from https://ci.netsurf-browser.org/builds/riscos/
it complains that there is no more room on the hard-disk (which actually has 245 Gb free).
So I downloaded netsurf-3/10/zip to my Raspbian machine, and transferred it by FTP to my RISC OS machine. But when I try to run it I get an Abort on data transfer error.
So I am a bit stuck.

What is the checksum of the download at each step? *md5 gives e94733e7c42ec284923eb2c8117707af here and netsurf 310 runs

Yes that is the md5 checksum for netsurf-3/10/zip that I have too. But when I doubleclick the !NetSurf that it contains I get “Application may have gone wrong” with "undefined instruction at &004C2720. I suspect it is a !SparkFS problem. Mine says: SparkFS 1.46 (06-Jul-20). I have also tried with SparkFS 1.45 and 1.44. They all unzip OK but the results are the same.

Should you be running from the zip file – aren’t you extracting it to a folder first?

Yes I am. Sorry for not being explicit enough.
I seem to be having a storm of problems: gcc 4.7.4-rel5 does not work (unable to locate GOT of client), Netsurf does not work (no room for download)
so I am wondering if this could be faulty RAM. Are there any RAM checking tools out there? Or do I write a BASIC program to set and read addresses?

Netsurf does not work (no room for download)

I noticed in another thread you said that you have Scrap on you RAM disc. Untl you drag the file somewhere NetSurf starts downloading it to Scrap, so it could be having free space on the RAM disc that matters here.

If it is Netsurf and GCC that are the primary problems

NetSurf now uses Shared Libraries and SOManager? Since when?

As I understand it, SOManager is a bloody nuisance. It is absolutely responsible for the problems I’m having with Paint, and I have no doubt that it is also why it took me half an eternity (and sore arms) to get the strimmer started.

I wouldn’t be at all surprised to find out that a certain viral issue of relevance right now is also SOManager’s fault.

🤣

Okay then.

I used Netsurf 3.8 to download Netsurf 3.10 which was unpacked using SparkFS 1.45.
Then, after reading your first message properly ;-) I used Netsurf 3.10 to download 3.11 #5312.

Seems to work as expected on my ARMv7 Pi2.

undefined instruction at &004C2720

It’s a regular instruction in the function VP8InitIoInternal :

004C26E4 : .Vs. : 0073561C : RSBEQS  R5,R3,R12,LSL R6
004C26E8 : VP8I : 49385056 : LDMMIDB R8!,{R1,R2,R4,R6,R12,R14}
004C26EC : nitI : 4974696E : LDMMIDB R4!,{R1-R3,R5,R6,R8,R11,R13,R14}^
004C26F0 : oInt : 746E496F : STRVCBT R4,[R14],#-2415
004C26F4 : erna : 616E7265 : Undefined instruction
004C26F8 : l... : 0000006C : ANDEQ   R0,R0,R12,RRX
004C26FC : ...ÿ : FF000014 : ; func: VP8InitIoInternal
004C2700 : .À á : E1A0C00D : MOV     R12,R13
004C2704 : .Ú-é : E92DDA00 : STMDB   R13!,{R9,R11,R12,R14,PC}
004C2708 : .°Lâ : E24CB004 : SUB     R11,R12,#4
004C270C : ..]á : E15D000A : CMP     R13,R10
004C2710 : Âï.» : BB03EFC2 : BLLT    &005BE620
004C2714 : .ÐMâ : E24DD008 : SUB     R13,R13,#8
004C2718 : .‘ á : E1A0900D : MOV     R9,R13
004C271C : ..⇒å : E5890000 : STR     R0,[R9,#0]
004C2720 : ..⇒å : E5891004 : STR     R1,[R9,#4]
004C2724 : .0−å : E5993004 : LDR     R3,[R9,#4]
004C2728 : C4 á : E1A03443 : MOV     R3,R3,ASR #8
004C272C : ..Sã : E3530002 : CMP     R3,#2

Prior to trying Netsurf, can you:

Set Debugger$DumpOptions -file annotated
Set Debugger$AnnotatedFile $._nscrash

When it crashes, can you do:

*Where
*MemoryI PC-20 +40

to see what’s going on around the point of crash.

There will also be the file $._nscrash that should unwind things a little.

Working out what’s going wrong is likely above my pay grade, but if you post the two bits here (if there’s a lot of repeated stuff at the end of the debugger dump, you can usually clip that off) somebody might spot a possible reason.

have you tried to see if the error accrues on a low-vector ROM

Won’t be that. It’s an undefined instruction. Things that are sensitive to high vector (in other words, bad code with uninitialised pointers) throw data aborts, not undefined instructions.

I seem to be having a storm of problems: gcc 4.7.4-rel5 does not work (unable to locate GOT of client), Netsurf does not work (no room for download)

gcc watches Game Of Thrones? Yikes!

More seriously – have you given your disc a pass with DiscKnight? It’s possible that things are just really messed up on the disc?

The last memory checking tool that I knew of was a little program back in the RISC OS 2 days. It wouldn’t take much to put together a few simple tests in BASIC. Doesn’t matter if it runs slowly, you’re only looking for a pass or fail.

If it is memory… are you overclocking? Have you tweaked the timing of anything at all? (refer to CONFIG.TXT in the DOS partition)

More seriously – have you given your disc a pass with DiscKnight? It’s possible that things are just really messed up on the disc?

DiscKnight only checks filing system metadata, it wont spot the contents of a file have been messed up (although very likely if it ever says multiply linked).

If it is memory… are you overclocking?

Underclocking I think, a Pi 1B is just too gawdamn fast for some.

(although very likely if it ever says multiply linked)

That’s exactly it.

Thanks Rick for your suggestions. The Rpi3B+ is not overtclocked. It has 2Gb of microSD card holding the RO5.28 ROMS. DiscKnight reported it as good. It also has 256 Gb on HardDisc. DiscKnight reported two faults, which it has repaired and now reports it as fault free. I followed your instructions.
After trying to run NetSurf 3.20 :

*where
Address &004C2724 is at offset &004BA724 in application memory

I wrote this very primitive BASIC RAM checker

REM Check memory
ON ERROR PRINT ERL;REPORT END
P%=END
N%=162780
PROCwrite
PROCread
PRINT "-------"
END
DEFPROCwrite
FOR I%=0 TO N%-1
 P%!(4*I%)=I%
NEXT
ENDPROC
DEFPROCread
FOR J%=0 TO N%-1
 IF P%!(4*J%) <> J% THEN
  PRINT "Bad ";STR$~(P%+(4*J%))
 ENDIF
NEXT
ENDPROC
If N% is increased it crashes with lots of 2's going across the taskwindow. It gives<pre><code>Bad 9038
Bad 903C
Bad 9040
Bad 9044
Bad A7F6C
Bad A7F70
Bad A7F78
Bad A7F7C
Bad A7F80
Bad A7F84
-------

Whether or not the above BASIC program made any sense, I am pretty sure my troubles were down to memory defects – the first time I have encountered them on a Raspberry Pi. In place of the Rpi3B+ I slotted in an older Rpi3B, redownloaded the necessaries, and everything now works.

@Julie
Your remark was on the nail. It explained completely why NetSurf was not downloading properly. Increasing the RAM disk size dealt with it.

I redownloaded the appropriate files for using !GCC 4.7.4-rel5-1 and it now works properly. Thanks to everybody for their suggestions. I suspect that the memory defect occurred some while ago, when I was having problems with Messenger Pro.

Are there any RAM-checking tools around?

I wrote this very primitive BASIC RAM checker

The ‘Bad’ addresses &90xx are because the PROCs will change the value of END to register their names etc, so PROCwrite will overwrite them … I am suprised it did not cause big problems.

The ‘Bad’ addresses &A7Fxx are probably because you have overwritten some values in the BASIC stack – you do no checks on the end on HIMEM, MEMLIMIT or the stack. The only safe areas to write in BASIC in this way are between HIMEM and MEMLIMIT.

But sorry, I do not know of any other checking tools.

I wrote this very primitive BASIC RAM checker

I’d just suggest DIM-ing a large block and checking that.

You could load your NetSurf zip into a RAM disc and md5sum it from there repeatedly.

Does the Pi 3B+ have higher current requirements than the Pi 3B? Are you supplying it with enough juice?

DiscKnight reported two faults

Do you remember what?

I ask because some things (like the aforementioned multiply linked blocks) can have knock on effects that aren’t directly detectable.

The !RunImage file has &6C117570 (undefined instruction according to StrongED in dump mode) at &004BA724.

Did you unsqueeze the program first? ;-)

[although, in my compressed RunImage it is something like SWIPL as it’s data…?]

I followed your instructions.

And the exception dump?

and everything now works.

Well, that certainly points to the 3B+.

Are you sure your power supply and cables are up to it? The 3B+ takes around 45% more power than the normal 3B; whether under load or idling.

If you aren’t using it as your RISC OS machine, you could always try an alternative OS on it, to see if that misbehaves?

On Raspbian or whatever it’s called now, this ought to work:

sudo apt-get update
sudo apt-get install memtester
sudo memtester <mem> <loops>

Set mem and loops accordingly.

Instructions for memtester: https://linux.die.net/man/8/memtester

The 3B+ takes around 45% more power than the normal 3B; whether under load or idling.

I had forgot that the 3B+ was so much thirstier. I suppose I should chuck it in the bin now. I still have two 3Bs, which are adequate for my RISC OS needs for the moment.

Feel free to chuck it my way.

I suppose I should chuck it in the bin now.

Don’t bin it until you’ve tried it with beefier power arrangements – that means PSU and cable must both be up to the job.

Just a thought

Thanks. I am going to send it to Rick as he has more understanding of these matters than I and he has offered to probe it. On the Pi 3B, gcc 4.7.4-rel5-1 works properly too, albeit slowly.