Who likes manga?

Hi Rick,

Thanks for the update but it will still not run on the ARMX6 here.

I have also tried putting ALL of the existing boot/disc structure in to another directory called Hide and then installing the latest ROOL boot sequence and using that but it still aborts.

This just leaves the actual ROM or CMOS file or some iMX6 type specific.

The latest error is:

“Internal Error, trap while in trap handler: Not Enough memory, stack overflow, pc=FC16803C , Registers at 00021A10.

Using Where shows the issue is in the SharedCLibrary area?

I have tried increasing the Wimpslot memory but still get the issue.

Doug sent me the following in response to the original report:

Error block: 80000002 Internal error: abort on data transfer at &2069AB9C
R0 = 2065ea40
R1 = 00000009
R2 = 00827fff
R3 = 00000030
R4 = 00000000
R5 = 2076839d
R6 = 20768694
R7 = 00000000
R8 = 00000000
R9 = 00000001
R10 = fa20021c
R11 = fa207eb4
R12 = ffec6804
R13 = fa207e08
R14 = 00827efe
R15 = 2069aba4
CPSR = a0000113
R13_usr = 006edf8c
R14_usr = 0000a860
R13_svc = fa207e08
R14_svc = 00827efe
SPSR_svc = 40000193
R13_irq = fa102000
R14_irq = a0000113
SPSR_irq = a0000113
R13_abt = fa301fa8
R14_abt = 2069aba4
SPSR_abt = a0000113
R13_und = fa402000
R14_und = fc182e3c
SPSR_und = 20000113
OSMem16: 2 = fa100000, 00002000, 00002000
OSMem16: 3 = fa200000, 00008000, 00008000
OSMem16: 4 = fa300000, 00002000, 00002000
OSMem16: 5 = fa400000, 00002000, 00002000
Memory: fa100000 - fa102000
Memory: fa200000 - fa208000
Memory: fa300000 - fa302000
Memory: fa400000 - fa402000
Memory: 00000108 - 0000010c
OSRSI6: 69 = 00000108

R15 = 2069aba4 = AcornHTTP +bd90
R14_svc = 00827efe = +81fefe in application memory

SVC stack:
fa207e08 : 01010417 :
fa207e0c : 0000003f :
fa207e10 : 000001ff :
fa207e14 : 20769424 :
fa207e18 : 20768bc4 :
fa207e1c : 00000000 :
fa207e20 : 00000000 :
fa207e24 : 006ef0d6 :
fa207e28 : 006ee1d7 :
fa207e2c : 2076866e : - Return to 2076866e?
         :          : | = Module area +76866e
fa207e30 : ffffffff :
fa207e34 : 00000000 :
fa207e38 : 20769694 :
fa207e3c : 20768694 :                                            - R4
fa207e40 : 207682bc :                                            | R5                                       - R4
fa207e44 : 00000005 : - Return to 00000005?                      | R6                                       | R5
         :          : | is system workspace                      |                                          | 
fa207e48 : 000003b8 :                                            | R7                                       | R6
fa207e4c : 0000001d : - Return to 0000001d?                      | R8                                       | R7
         :          : | is system workspace                      |                                          | 
fa207e50 : 2065ea40 :                                            | R9                                       | R8
fa207e54 : 20698640 :                                            | R14: 20698640 (ASM call to 2069a834)     | R11
         :          :                                            | 20698640 = AcornHTTP +982c               | 
         :          :                                            | 2069a834 = AcornHTTP +ba20               | 
fa207e58 : fa207e64 :                                                                                       | R12
fa207e5c : 00000000 :                                                                                       | R14: 00000000
         :          :                                                                                       | is system workspace
fa207e60 : fc366db4 :                                                                                       | APCS function: fc366dac
         :          :                                                                                       | = Internet +177b8
         :          :                                                                                       | = sock_swi_handler +4
fa207e64 : 00000400 :
fa207e68 : 00060300 :
fa207e6c : 00000400 :
fa207e70 : 00001000 :
fa207e74 : 00000400 :
fa207e78 : 00001000 :
fa207e7c : 006ee1d8 :
fa207e80 : 20768700 :
fa207e84 : 20768984 :
fa207e88 : 2065ea40 : - R0
fa207e8c : 00000000 : | R1
fa207e90 : 2065e9b4 : | R4
fa207e94 : 0000071b : | R5
fa207e98 : 20602c34 : | R6
fa207e9c : 00000311 : | R7
fa207ea0 : fa207ef8 : | R8
fa207ea4 : 00000023 : | R9
fa207ea8 : fa207ee0 : | R11
fa207eac : fa207eb8 : | R12
fa207eb0 : 20691f1c : | R14: 20691f1c
         :          : | = AcornHTTP +3108
fa207eb4 : 20697618 : | APCS function: 20697610
         :          : | = AcornHTTP +87fc
fa207eb8 : 2065ea40 : | 
fa207ebc : fa207f58 : | R4
fa207ec0 : 2065e9b4 : | R5
fa207ec4 : 006ee1d8 : | R6
fa207ec8 : 00001000 : | R7
fa207ecc : 20602c34 : | R8
fa207ed0 : 00000000 : | R9
fa207ed4 : fa207f1c : | R11
fa207ed8 : fa207ef4 : | R12
fa207edc : 20694708 : | R14: 20694708
         :          : | = AcornHTTP +58f4
fa207ee0 : 20691e0c : | APCS function: 20691e04
         :          : | = AcornHTTP +2ff0
fa207ee4 : 2065e9b4 : | 
fa207ee8 : 006ee1d8 : | 
fa207eec : 00001000 : | 
fa207ef0 : 0000071b : | 
fa207ef4 : fa207ef8 : | 
fa207ef8 : 20118674 : | 
fa207efc : 2065e9b4 : | R4
fa207f00 : fa207f58 : | R5
fa207f04 : 00000000 : | R6
fa207f08 : 00000000 : | R7
fa207f0c : 20000113 : | R8
fa207f10 : fa207f38 : | R11
fa207f14 : fa207f20 : | R12
fa207f18 : 20694984 : | R14: 20694984
         :          : | = AcornHTTP +5b70
fa207f1c : 2069462c : | APCS function: 20694624
         :          : | = AcornHTTP +5810
fa207f20 : fa207f58 : | R4
fa207f24 : 006ee1d8 : | R5
fa207f28 : 00001000 : | R6
fa207f2c : fa207f54 : | R11
fa207f30 : fa207f3c : | R12
fa207f34 : 2069445c : | R14: 2069445c
         :          : | = AcornHTTP +5648
fa207f38 : 20694834 : | APCS function: 2069482c
         :          : | = AcornHTTP +5a18
fa207f3c : 2449b454 : | R4
fa207f40 : 00002458 : | R5
fa207f44 : 006ee058 : | R6
fa207f48 : 00000000 : | R11
fa207f4c : fa207f58 : | R12
fa207f50 : 2068f158 : | R14: 2068f158
         :          : | = AcornHTTP +344
fa207f54 : 2069443c : | APCS function: 20694434
         :          : | = AcornHTTP +5620
fa207f58 : 00000000 : | R0 \ CMHG veneer _kernel_swi_regs?
fa207f5c : 205da254 : | R1 |
fa207f60 : 006ee1d8 : | R2 |
fa207f64 : 00001000 : | R3 |
fa207f68 : 00000000 : | R4 |
fa207f6c : ffffffff : | R5 |
fa207f70 : 006ee058 : | R6 |
fa207f74 : 00000000 : | R7 |
fa207f78 : 00000000 : | R8 |
fa207f7c : 00000000 : | R9 /
fa207f80 : fc020694 : - fc029468 return to fc020694?
         :          : | fc029468 = +29468 in the Kernel
         :          : | = CallVector +0
         :          : | fc020694 = +20694 in the Kernel
         :          : | = VectorUserSWI +8
fa207f84 : 60000113 : - PSR?
fa207f88 : 000a3f82 : | SWI XHTTP_ReadData
fa207f8c : fc1676a8 : | R14: fc1676a8
         :          : | = SharedCLibrary +32278
         :          : | = _kernel_swi +18
fa207f90 : fa20021c : | R10
fa207f94 : 00000000 : | R11
fa207f98 : 000a3f82 : | R12
fa207f9c : fa207fbc :
fa207fa0 : 2449a020 :
fa207fa4 : fff63a1c :
fa207fa8 : 006ee058 :
fa207fac : 00000000 :
fa207fb0 : 20000113 :
fa207fb4 : 00000000 :
fa207fb8 : 205fc53c : - 205fcc30 return to 205fc53c?
         :          : | 205fcc30 = URL_Fetcher +a5c
         :          : | 205fc53c = URL_Fetcher +368
fa207fbc : 00000000 :
fa207fc0 : 205da254 :
fa207fc4 : 006ee1d8 :
fa207fc8 : 00001000 :
fa207fcc : 00000000 :
fa207fd0 : ffffffff :
fa207fd4 : 006ee058 :
fa207fd8 : 00000000 :
fa207fdc : 00000000 :
fa207fe0 : 00000000 :
fa207fe4 : fc020694 : - fc029468 return to fc020694?
         :          : | fc029468 = +29468 in the Kernel
         :          : | = CallVector +0
         :          : | fc020694 = +20694 in the Kernel
         :          : | = VectorUserSWI +8
fa207fe8 : 60000110 : - PSR?
fa207fec : 000a3e03 : | SWI XURL_ReadData
fa207ff0 : fc1676a8 : | R14: fc1676a8
         :          : | = SharedCLibrary +32278
         :          : | = _kernel_swi +18
fa207ff4 : 006edfa0 : | R10
fa207ff8 : 000239b8 : | R11
fa207ffc : 000a3e03 : | R12

R14_usr = 0000a860 = +2860 in application memory = fetcher_fetch_assl +58c
          Function call to fc167690 = SharedCLibrary +32260 = _kernel_swi +0

USR stack:
006edf8c : 00021224 : - R2
006edf90 : 00021224 : | R4
006edf94 : 000000f4 : | R5
006edf98 : ffffffff : | R6
006edf9c : 205da254 : | R7
006edfa0 : 000000c8 : | R8
006edfa4 : 00000000 : | R9
006edfa8 : 0000a860 : | R14: 0000a860 (ASM call to fc167690)
         :          : | 0000a860 = +2860 in application memory
         :          : | = fetcher_fetch_assl +58c
         :          : | fc167690 = SharedCLibrary +32260
         :          : | = _kernel_swi +0
006edfac : 00000000 :
006edfb0 : 00000000 :
006edfb4 : 00000000 :
006edfb8 : 00000001 :
006edfbc : 00000640 :
006edfc0 : 00269cd9 :
006edfc4 : 00269ce5 :
006edfc8 : 00000000 :

What is going on is that I am calling XURL_ReadData repeatedly in the fetcher_fetch_assl function, using _kernel_swi.
It returns a status of zero many times (setting up the connection), then it returns a status of 31 numerous times (connection in progress). Then it returns a status of 31 with an HTTP response of 200 three times (it has sent the headers and got an OK back from the server). At the point where it would actually begin to send back data, it crashes.

As can be seen from previous messages, it works fine in a Pi2 (mine and Willard’s) as well as working on a different ARMX6 with the same OS. The memory being written to is defined as char workspace[4128] in the fetcher function, so there shouldn’t be any issue of oops forgot to set the pointer.
Plus, until Doug’s report, I hadn’t even touched that bit of code compared to others.

Sadly the exception dump doesn’t give any disassembly around the failure point, but my go-to in data transfer aborts is to suspect that something is playing around in zero page. But without anything to confirm this (and, anyway, why?)…

Does anybody have any ideas?

To follow up, here’s the code that calls ReadData:

      r.r[0] = 0;    // Flags, SBZ
      r.r[1] = session;
      r.r[2] = (int)workspace;
      r.r[3] = 4096; // workspace size 
      if ( _kernel_swi(0xA3E03 /* XURL_ReadData*/, &r, &r) != NULL )
      {
         fetcher_deregister(session);
         File_Close(ofp);
         File_Delete(filename); // don't leave junk in the cache
   [...etc...]

SWI number hardcoded because while SWI_URL_ReadData is defined in DeskLib now, it wasn’t when I first wrote this.

Here’s the SWI spec:

SWI URL_ReadData (&83E03)

On entry:
        R0:     Flags:
                Bits 31-0 reserved (0).
        R1:     Session identifier.
        R2:     Client buffer for received data.
        R3:     Size of buffer pointed to by R2.

On exit:
        R0:     Status word (see SWI URL_Status).
        R2:     Preserved. Contents of buffer modified.
        R4:     Number of bytes transferred to R2 buffer.
        R5:     Number of bytes still to be read to complete object
                (if known) or -1 if unknown.

        All other registers preserved.
        SWI is not re-entrant.
        Interrupt status undefined.

suspect that something is playing around in zero page

So just got me thinking as I have the Low Vector RComp 5.29 3rd Nov 2020 ROM installed.

So I installed the High Vector of the same ROM and still get the same issue.

I then went back to an earlier 5.27 ROM dated 20th September 2020 and still get the same issue.

I was going to try the latest ROOL Wandaboard ROM but the archive in the downloads seems corrupted and I have posted a report about that.

For what it’s worth, 0.54 seems to be fine on my Pi 4 with OS 5.28.

0.54 is OK on my armv7 pi2, riscos 5.28

OK fixed the issue now and it seems it may be done to an issue with the ROOL Hard disc build/download specifically the AcornHTTP module.

So I have installed the module from the 26th January 2021 dowload and it
reports it’s self as 1.04 (22 Apr 2020) and is 42400 in size.

With this loaded Manga 0.54 and Recce 1.03 either abort or lock up the ARMX6.

I deleted this and added the module made available via Sine Nomine’s
System downloads for Recce and RISCOsm.

It reports it’s self as 1.04 (22 Apr 2020) but is 42312 in size!

I then tried Manga 0.54 and it works and doesn’t abort and also Recce 1.03 works as well.

Looks like a build issue with the ROOL components?

Hope this helps but I guess the other questions is why would a component that has the same module number/date change it’s value without being incremented..wait I better not go there..

I think it’s a problem with the build system, as the history for the AcornHTTP module doesn’t indicate multiple versions with the same number – https://gitlab.riscosopen.org/RiscOS/Sources/Networking/Fetchers/HTTP/-/commits/master/VersionNum

Strange thing is, I’ve been running 1.04 for a while (and Manga has required it for a while because SNI). So when and where did this change occur?

I’ll check mine when I get home (downloaded from ROOL when 1.04 was first released) to see if it’s the known good or the known bad.

So when and where did this change occur?

So depends on what change/s as from the downloads i have:

04/09/20 – AcornHTTP 1.04 22 Apr 2020 Size 42312 so the same
19/10/2020 – 5.28 download – AcornHTTP 1.04 22 Apr 2020 Size 42300
25/10/2020 – 5.29 Beta – AcornHTTP 1.04 22 Apr 2020 Size 42300
22/12/2020 – 5.29 Beta – AcornHTTP 1.04 22 Apr 2020 Size 42400

So multiple changes not just one then, change control at it’s finest :-)

Update: Just tried the 42300 sized AcornHTTP and it seems to work so perhaps the changes introduced that changed it to 42400 size is the area to concentrate on.

The first time my watch script saw the 42300 byte one was 7 July 2020 (file date 29-06-2020). The 42400 byte one came first on 30 October (22-10-2020).

Hi Frank,

Thanks for that information hopefully it will help Rick identify the issue or at least help ROOL identify it as well.

Mine, that works on my Pi2, is 42300 bytes. It is datestamped 23rd August 2020. It will have come from the beta Harddisc4.

change control at it’s finest :-)

Something is actually going horribly wrong.

The link I gave, with the unique version numbers, is the “VersionNum” file.

Looking at the history of c.security, ROOL created v1.01 and Matthew Philips updated it to v1.04 to support SNI.

The history of c.connect is similar. Stewart Brodie (!) made a change for 0.83 a mere 22 years ago, and more recently Matthew updated to 1.04 for the SNI support.

The h.module file, likewise updated.

So unless somebody has been fiddling with the underlying build process, I don’t see where these variants are coming from. It’s not like there are multiple checked in sources all tagged with the same version number.

hopefully it will help Rick identify the issue

I’m just a client of AcornHTTP. At least now I know it’s not my code. ;-)

On the flip side, given that we appear to have multiple different modules with the same version number, it does make it difficult to know how to deal with this programmatically. Interrogate the module and see if it is 42400 bytes long?

or at least help ROOL identify it as well.

We ought to – once the problem has been tracked down – have an immediate version bump to 1.05 so we can RMEnsure that, and skip over this unfortunate mess.

So multiple changes not just one then, change control at it’s finest :-)

Possibly because the last change to the AcornHTTP module was on 22 April 2020, as the module’s date says?

Presumably you’re looking for a change to a library that it links to, or a change to the toolchain or build parameters?

I’m not going to dive too deeply into this, looking at compiled code makes my head hurt.

Doug send me a good and a bad module. Superficially they are the same until the function at &9508, which is this in the good one:

|L00009508|
        LDR     a1,[sp,#&010]                   ; =16
        MOV     a1,a1,LSR #16
        CMP     a1,#&10                         ; =16
        BCS     |L00009550|
        LDRB    a1,[sp,#&011]                   ; =17
        LDR     a3,[sp,#&010]                   ; =16
        LDRB    a4,[sp,#&011]                   ; =17
        MOV     v5,v5,LSR a1
        LDR     a1,[v1,#&068]                   ; =104
        MOV     a3,a3,LSR #16
        SUB     v3,v3,a4
        ADD     a2,a1,#1
        STR     a2,[v1,#&068]                   ; =104
        ADD     a1,v1,a1,LSL #1
        MOV     a2,a3,LSR #8
        STRB    a3,[a1,#&070]                   ; =112
        STRB    a2,[a1,#&071]                   ; =113
        B       |L000096DC|                     ; Ends

And this in the bad one:

|L00009508|
        LDRB    a1,[sp,#&013]                   ; =19
        LDRB    ip,[sp,#&012]                   ; =18
        MOV     a1,a1,LSL #24
        ORR     a1,a1,ip,LSL #16
        MOV     a1,a1,LSR #16
        CMP     a1,#&10                         ; =16
        BCS     |L00009560|
        LDRB    a1,[sp,#&011]                   ; =17
        LDRB    ip,[sp,#&012]                   ; =18
        LDRB    a3,[sp,#&013]                   ; =19
        MOV     v5,v5,LSR a1
        LDR     a1,[v1,#&068]                   ; =104
        LDRB    a4,[sp,#&011]                   ; =17
        ORR     a3,ip,a3,LSL #8
        ADD     a2,a1,#1
        STR     a2,[v1,#&068]                   ; =104
        ADD     a1,v1,a1,LSL #1
        MOV     a2,a3,LSR #8
        SUB     v3,v3,a4
        STRB    a3,[a1,#&070]                   ; =112
        STRB    a2,[a1,#&071]                   ; =113
        B       |L000096F8|                     ; Ends

After resyncing visually, a little further down, the good:

|L000095C4|
        LDR     a1,[sp,#&010]                   ; =16
        MOV     a1,a1,LSR #16
        CMP     a1,#&11                         ; =17
        LDRB    a1,[sp,#&011]                   ; =17
        BNE     |L0000962C|
        ADD     a2,a1,#3
        CMP     a2,v3
        BLS     |L00009604|

And the bad:

|L000095D4|
        LDRB    a1,[sp,#&013]                   ; =19
        LDRB    ip,[sp,#&012]                   ; =18
        MOV     a1,a1,LSL #24
        ORR     a1,a1,ip,LSL #16
        MOV     a1,a1,LSR #16
        CMP     a1,#&11                         ; =17
        LDRB    a1,[sp,#&011]                   ; =17
        BNE     |L00009648|
        ADD     a2,a1,#3
        CMP     a2,v3
        BLS     |L00009620|

There are similar changes (around &9968 good or &9984 bad; &99D0/&99F8, &9B3C/&9B70, and so on) which appear to be LDRs replaced by LDRBs.

Not sure if this is the build environment or a library. No embedded function names. Strings around that point are “invalid bit length repeat” and “invalid literal/length code”.

It’s ZLib – either c.inflate or c.infback.

Both (ZLib and ZLibMod) say in the overview (if you go to Projects and look for “ZLib”) that they were last updated 3 months ago.
If you follow either, it says the last update was a year ago, Timothy Balwin modified the MakeFile, however looking at the actual code… last modified eight years ago.

Presumably you’re looking for a change to a library that it links to, or a change to the toolchain or build parameters?

As I said earlier:

Looks like a build issue with the ROOL components?

To me it is splitting hairs if the resultant component outputted is changed and not the same then it should have a change status even if it is say a build identifier ID.

The same thing has been discussed about how do you know the AcornSSL module is up to date when the system just looks at the module details not the bit about mbedTLS version.

It just makes finding issues harder for developers let alone us end users.

Anyway Rick has highlighted the offending bits so hopefully someone can see the issue and fix the build/library.

To me it is splitting hairs if the resultant component outputted is changed

Yes, it’s an interesting question, that.

Personally, I subscribe to the idea of “not binary identical, not the same version”. I’m not going to discuss AcornSSL at all else I’ll start getting sweary. Not binary identical. Not binary identical. Not <bleeeep>ing binary identical!!!1!!ONE!!!

I agree with Rick totally. Binary change => version change.
The history of a module should also indicate when libraries used have changed – this is a problem that will get worse and worse as more are moved from assembler to C. Eventually a library could change which affects many many modules, and unless they change version problem diagnosis will be impossible.

I agree with Rick totally. Binary change => version change.

Definitely. Any other view is just bull****

Why are there no names/procedures in the code?

To me it is splitting hairs

Not really, because you’re looking for a change in a different chunk of code – as Rick has confirmed. Looking for a change in the AcornHTTP source would have got you precisely nowhere, because there were no changes to it after the date baked into the module.

Sorry if you thought that the time I spent looking at the changelogs was a waste – I’ll not bother in future.

The history of a module should also indicate when libraries used have changed

So how can this be done?

That’s a serious question, as it’s a problem that hits application developers when they build and release things too, so having a solution would be extremely useful. Module versions in RISC OS are stored in the source files, and so unless you plan to manually find all of the dependents and bump their versions by hand when a library changes, you’re going to have to automate the process.

How does one do that, whilst sticking with meaningful version numbers and remembering that we’re spanning multiple repositories?

as it’s a problem that hits application developers when they build and release things too,

I think the difference is that many developers build something, and release it. The next iteration is built, and released.

This module, the whole ROOL thing, and possibly anything in the GCCSDK autobuilder, is built over and over and over. If anything the code relies upon should change, then this is silently incorporated without any notification, leading to different versions of what is supposed to be the same thing.

I mean, there’s a version 1.04 of the AcornHTTP module. Does it need to be constantly rebuilt? If a dependency has changed, can Git flag this somehow?

Looking for a change in the AcornHTTP source would have got you precisely nowhere,

I know. I did. And it did. ;-)

Thankfully, Doug thought to email me the working and borked versions of the modules, so I tossed them both to Armalyser, and such Diff wet itself, I simply put the two files side by side in Zap and just hit Page Down a lot looking for when things started to fail to line up.
Then, since nothing has function names in it (another impediment to debugging), I looked around near the differences to see if I could find any strings. I did. I checked the entire AcornHTTP source (a slightly older version, but the text looked more like something to do with compression than SNI). Nothing. So I checked the entirety of the networking libraries (looking at the ALF files). Nothing. So I looked at the MakeFile and noticed that it specified ZLib. I didn’t have that in my older source collection, so I pulled it from GitLab and… bingo! Found it.

How and why it’s different, I don’t know. As I said, looks broadly like LDRs changed to lots of LDRBs. Which clearly aren’t having the same effect. Is this a compiler flag? It doesn’t look like the source has changed at all recently.

Both (ZLib and ZLibMod) say in the overview (if you go to Projects and look for “ZLib”) that they were last updated 3 months ago. If you follow either, it says the last update was a year ago

This looks as if it could be a GitLab “feature”, in that the last modification time in the group list takes into account other stuff then just when the repository content changed. There seem to be several discussions about the desirability (or otherwise) of this behaviour in their tickets.

Sorry if you thought that the time I spent looking at the changelogs was a waste – I’ll not bother in future.

Steve that wasn`t what I was saying or implying and thank you for looking.

Further I was merely pointing out that if something is different be it code changes, build dates, binary output then you need to be able to identify it as that makes it eaiser to pin things down.

As far as I was concerned I saw the same date and module number etc and therefore until I saw the differnet code size for all intents and purposes it was the same module.

As I said I thought once I saw the diffewrnet size it was more “build environment” than actual code change.

The build environment is just as much part of the change control process as everything else and it may be going forward things need to be improved in this area to help end users help developers find issues better.

One is sign-extending? Oh, it isn’t! Different compiler then.