e-Mail lost connections

I’ve been unable to retrieve some of my e-mails using NetFetch (5·51, dated 21 Oct 2019)/Messenger Pro (8·04, dated 20 Aug 2019) since I updated my ROM image (5·27) and Boot from HardDisc4 on a Pi3B on 24 Nov which I think was dated 22 Nov.

Errors show as “Connection lost” in the Hermes transfer status window for Gmail and Sky POP accounts. Accounts for Virgin, BT and GMX connect and transfer OK.

Having checked passwords and the other settings for the troubled accounts (all were OK), I tried later downloads with the same results. I created a new card image with later ROM and HardDisc downloads and fresh installs of NetFetch/Messenger, giving the same results.

Thinking that it may be the AcornSSL module, I replaced this module in todays (1 Dec 2019) HardDisc4 download with the version in my most recent working system (28 Oct 2019) and all connections are OK. ie Before the replacement, errors occurred; replacing the module and re-booting, all OK.

Comparing the modules from 28 Oct and 1 Dec I find they both give the same version number (1·05) and date (9 Sep 2019), but show different sizes (188316 and 188352 respectively) via Filer > Info.

Of course this may be just coincidence and it’s my settings in NetFetch/Messenger Pro or something else lurking on my system that are causing the problem. Any pointers would be much appreciated.

And, once again, the question arises of what the <expletive> is going on that we appear to have multiple versions of this module with the same version and the same date.
You know, the two bits of identifying information that’s supposed to tell different versions of the module apart…

we appear to have multiple versions of this module with the same version and the same date.

According to the commit log the source code for AcornSSL hasn’t changed since September. The module could also have been affected by changes to something else (e.g. the C compiler, or one of the shared libraries) which of course won’t change the version number.

Ok, I have tried an AcornSSL module from the 22nd September download and it identifies as AcornSSL 1.05 (09 Sep 2019) mbedTLS 2.16.3 file size 188316 and file date stamped as 22nd September 2019 and it works with my Gmail account.

AcornSSL from a download today identifies itself as the same module with a file size of 188352 and date stamped 1st Dec 2019 and that as Dave says fails with a connection lost error.

All this on a ARMX6 with RISC OS 5.25 (24th-Aug-18).

So it does perhaps look like a module build issue and perhaps one of the potential issues is as Stuart has identified.

A similar problem happens using AntiSpam and AcornSSL downloaded 01-Dec-19 and logging in to GMail. Gives error &813F27. Using a self built AcornSSL built from latest source as at 30-Nov-19 works OK.

Just a question to throw out there – is it only AcornSSL that is going wrong? Do the nightly builds work correctly? Has anybody tried comparing some of the other “yesterday” modules to see if they match up?

Just a thought, AcornSSL does not get used here so I have no first hand evidence, but is NetTime’s socket gobbling, or the fix, relevant at all.

Wrong again, the fault is with AcornSSL. See later post.

but is NetTime’s socket gobbling, or the fix, relevant at all.

Correct me if my memory is wrong but that involved a change to the NetTime module so it would be reasonable to unplug the NetTime module reboot and test – thus condemning or absolving NetTime.

There is a BASIC HTTP_Client test in git

As far as I can see the problem is with the current 188352 build, the earlier 188316 build is OK.

A build from the current DiscDev source tarball is also OK, as found by Chris Grandsen above. This weighs in at 188320.

The first AcornSSL module with the “problem” size (188352) appeared on 06 November. The Events page shows four changes were applied on 05 November:
zlib
ZLibMod
tokenise
Kernel

This may be sheer coincidence, of course.

As far as I can see the problem is with the current 188352 build, the earlier 188316 build is OK.

Has anybody cobbled together a program to dump the differences between the two modules? That might give an indication of what part is going wrong?

I can’t – my current version of the module is v1.04 (which has it’s own problems given there are two versions depending on which mbedTLS you have within it!).

I’ve just tried the borked 1.05 on my machine.

The test program to receive data from this site, appears to work.
Manga fails with a big number (probably an error block that wasn’t expected).

All works with my v1.04 version.

Note that my RISC OS is a self-build dating from 21st March 2017.

… dump the differences …

Not easy, as many register allocations have changed.

I have seen that there are six instances where
LDR R12,[R12,#0]
are now followed by an extra
TEQ R12,#0
and afterwards R12 is used, but now only if NE flag set.

If the source has not changed, could it be a debug switch or similar?

Another possibility is a change to the compiler itself. At the recent show, ROOL said that there’s a new version that’ll be formally announced soon. The autobuilder could already be using it.

I would have expected, if a change in the compiler that’s at fault, that more things would be falling over…

Compiler bugs (or dodgy source code) can be fickle like that.

I do have a copy of the new compiler (the free upgrades were sent out a couple of weeks ago) – I’ll do some experimenting tonight and see if I can reproduce the fault with my own builds.

more things would be falling over…

On a previous occasion when a compiler bug caused problems, it was first noticed in February 2018 and the second instance was reported ten weeks later.

If the bug only manifests itself in infrequently-used code, it’s going to take a long time to spot it.

the free upgrades were sent out a couple of weeks ago

Nothing has arrived here, was that a free general issue upgrade or part of beta testing?

I never did volunteer as a beta tester as all I do is build from sources, nothing original that is. In this case it might have been useful though I would probably have not discovered this issue for myself as AcornSSL does not get used here.

the free upgrades were sent out a couple of weeks ago

Nothing has arrived here, was that a free general issue upgrade or part of beta testing?

A non-beta, “you qualify for a free upgrade to the new DDE” upgrade.

Yep, looks like it’s a compiler bug.

https://www.riscosopen.org/tracker/tickets/477

And this is why god gave us artifact repositories.

You build something, you give it a version number, you upload to the repository, where it never changes again. Any subsequent builds that need to include that artifact retrieve it (by version) from the repository. If the code for the artifact changes, or one of its dependencies changes (and it’s statically linked), a new versions is built and uploaded to the release repository.

If you want a ‘latest and greatest’ version available, you designate it a snapshot and timestamp it – and then everyone knows by looking at the version info exactly what they’ve got.

A released artifact should never get rebuilt and should definitely never have potentially different contents day-to-day. If I let that kind of nonsense happen in my day job, I’d be searching for new employment pretty quickly.

I agree with Tony completely: it is ridiculous that we cannot tell the AcornSSL variants apart from the version number in the time-honoured RISC OS way, so that they can be RMEnsured accurately. And no doubt it affects many other components as well.

There were three AcornSSL v1.04 variants – for mbedTLS 2.16.0, 2.16.1 and 2.16.2

So far there have been three AcornSSL v1.05 variants – for mbedTLS 2.16.2 and 2.16.3 (dated 9 Sep 2019), plus the broken one also dated 9 Sep 2019. When the compiler is mended, there will presumably be at least one more.

I would suggest that if the recent build had been a new version, and there was some indication that it was because of a new compiler being used, then diagnosis of the problem would have been much quicker and would have wasted much less valuable time.

And many thanks to Jeremy for spending his very valuable time in identifying the cause.

Agreed. This needs to change. Different code (internally – not just source) is different version. Period.

Tony: +1

I had previously been documenting which DDE (implying compiler version) was used to build each PipeDream but not Fireworkz (I’ll go back and do that). Given the above I’ve started to dump the output of DecAOF of each application’s o.version into a human-readable file accompanying the distribution [Edit: to show the compiler version used]. I had noted some rather odd 64-bit code produced by cc 5.79 but not actually totally wrong as in Jeffrey’s bug report.

Yep, looks like it’s a compiler bug.

Ah. 64 bit. That’ll be why the rest of RISC OS wasn’t affected. :-p

As for the version issues, haven’t I been saying that for ages?

It may be “complicated” to get RISC OS to build only the stuff that has changed rather than “everything”, but that’s not such a big problem. Indeed it has been useful in shaking out a compiler bug that might not have been noticed otherwise.
However, different source equals different version.

Anything else is unacceptable.

As for the version issues, haven’t I been saying that for ages?

Nemo, hobby-horse. Many +1’s