Newshound and Eternal September

I haven’t made any changes to the code anywhere near where floating point variables are used. Which begs the question: did you get these errors with the standard version of NH’s RunImage?

I did not get errors like this with standard version of NH Runimage.

I haven’t been able to find any information about these features in the docs that come with the DDE. Have I missed something, or are they really not documented?

and

C/C++ book (the one supplied with the DDE), page 32 (or 43 in the PDF).

You’ll want “-fnah” (the ‘f’ in the original means no function names, using ‘n’ instead says you want function names).
‘a’ checks for data flow anomalies, and ‘h’ checks that everything is declared in a header. It’s the same options that I use.

I’m going to make a copy of all this not, as you might think, to keep handy as a hint on how to set things up (which probably ought to be mentioned before page 43) but to be kept as proof that techies do read manuals

:)

Is it at all possible for RO build of the CLib to have Function / Proc names included?

Gerf made a Prog that would back pedal from an error address to print out the first function / Proc name it came to.

And if a Prog had terminated – use on the Run image file.

CMFE F0, #2

comes from the source line:

if (difftime(time(NULL),newsserver→cur_time)>2)

which is innocuous enough. Neither time(NULL) nor newsserver→cur_time is a floating point number – they are both time_t, which is defined in CLib.h.time as unsigned int. So the floating point value doesn’t exist until difftime() is executed.

It does remind me that, a few years back, I was looking at Javascript in NetSurf to do time operations, and I couldn’t get a consistent value of system time. It’s too long ago to remember the details, but I did conclude that it wasn’t the Javascript that was going wrong, it was getting the system time that was failing – intermittently, which made it impossible to put up a test case. I wonder if we’re seeing something related here?

How to work out what is in F0? There isn’t much code in front of the comparison between F0 and 2:

MOV     R0, #0
BL      &0001A37C
LDR     R1,[R6,#2524]
BL      &0001A374
CMFE    F0,#2

(The BL addresses vary according to the build, of course.) Presumably, the first two instructions are doing time(NULL), the third is getting newsserver→cur_time, and the fourth is doing… what? There has to be a subtraction and a conversion to double. The two BL addresses must be to the Shared C Library, as there’s just a large area of zeroes where they point to.

There must be a list of Shared C Library function entry points somewhere, which would make it possible to work out what functions are being called.

I’m on SharedCLibrary 6.08 (05 Sep 2020) – what’s your version, Chris?

I’m on SharedCLibrary 6.08 (05 Sep 2020) – what’s your version, Chris?

The same one as you.

For reference the latest error gave:
*where
Address &FC148E44 is at offset &00013A14 in module ‘SharedCLibrary’
*showregs
Register dump (stored at &2001C630) is:
R0 = 6075D91F R1 = E075D91E R2 = E075D91F R3 = 00000000
R4 = 0001B8E0 R5 = 0001A238 R6 = 0001D8E0 R7 = 0001A34C
R8 = 00000001 R9 = 0001A274 R10 = 0001FD44 R11 = 00020954
R12 = 6075D91F R13 = 00020920 R14 = 0000CC1C R15 = FC148E44
Mode USR32 flags set: nZCvqjggggeAift PSR = 60000110

Have you tried running your RunImage through Druck’s Armalyser?

I may have seen a Division by Zero error, seemingly provoked by Newshound v1.52-32

I can now corfirm that – had one today. Only other clues were a PM report which I did not have time to note – but next time I will!

So the floating point value doesn’t exist until difftime() is executed.

Yes, difftime is defined in the source as:

double difftime(time_t time1, time_t time0)
{   return (double)time1 - (double)time0;
}

Given that time_t is an unsigned int (under RISC OS and POSIX), and this is a simple subtraction, why on earth is it promoting everything to double? Especially given that that’s the only time double appears in the entire time source (...Sources.Lib.RISC_OSLib.c.time).

the first two instructions are doing time(NULL), the third is getting newsserver→cur_time

Yes, that makes sense.

and the fourth is doing… what?

Well, time() is &1A37C. This unknown call is &1A374, which is 8 less. In other words, two functions before time(). The answer is… kind of obvious. ;-)

        Entry   clock, imported, , , 0
        Entry   difftime, imported, , , 2
        Entry   mktime, imported, , , 1
        Entry   time, imported, , , 1
        Entry   asctime, imported, , , 1

There’s time(), and two before it is… difftime()! ;-)

It will have left the result in F0, so the final instruction is comparing that with two.

And when restarting NH and doing the failed fetch again, I got (with details this time!)…

20:45:21.90 ** Error **
  Error  : &80000200
  Message: Floating point exception: invalid operation
Floating point exception: invalid operation

Postmortem requested

fc160cf8 in anonymous function

14284 in anonymous function

  Arg2: 0×00013a5c 80476 → [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe24dcf8f]

  Arg1: 0×000216b8 136888 → [0×77654e3c 0×756f4873 0×4424646e

0×2e3e7269]

fc151630 in shared library function

83b4 in anonymous function
Address &FC160CF8 in Module   SharedCLibrary      @ &FC14D2F8 + &13A00

Register dump (at &200618F0) is:

pc  = &FC160CF8  Flags=&60000010=nZCv if  Mode=User 32 bit

r0  = &6075F4D1 : Ñôu` : 1618343121

r1  = &E075F4D1 : Ñôuà : 3765826769

r2  = &E075F4D1 : Ñôuà : 3765826769

r3  = &00000000 : …. :          0

r4  = &0001C50C : .Å.. :     115980

r5  = &0001AB5C : \«.. :     109404

r6  = &0001E50C : .å.. :     124172

r7  = &0001A9C4 : Ä©.. :     108996

r8  = &00000001 : …. :          1

r9  = &0001C514 : .Å.. :     115988

r10 = &00020914 : …. :     133396

r11 = &00021518 : …. :     136472

r12 = &6075F4D1 : Ñôu` : 1618343121

r13 = &000214E8 : è… :     136424

r14 = &0000CC18 : .Ì.. :      52248
Code around address is:

FC160CC0 : E28F0F08 : ..•â : ADR     R0,&FC160CE8

FC160CC4 : E3A02050 : P  ã : MOV     R2,#&50            ; =“P”

FC160CC8 : EA007D0B : .}.ê : B       &FC1800FC

FC160CCC : EAFFCBFD : ýË.ê : B       &FC153CC8

FC160CD0 : 00363743 : C76. : EOREQS  R3,R6,R3,ASR #14

FC160CD4 : 00353343 : C35. : EOREQS  R3,R5,R3,ASR #6

FC160CD8 : 00363343 : C36. : EOREQS  R3,R6,R3,ASR #6

FC160CDC : 00373343 : C37. : EOREQS  R3,R7,R3,ASR #6

FC160CE0 : 00363643 : C66. : EOREQS  R3,R6,R3,ASR #12

FC160CE4 : 00343743 : C74. : EOREQS  R3,R4,R3,ASR #14

FC160CE8 : 00353743 : C75. : EOREQS  R3,R5,R3,ASR #14

FC160CEC : E2202102 : .! â : EOR     R2,R0,#&80000000

FC160CF0 > E2211102 > ..!â : EOR     R1,R1,#&80000000

FC160CF4 : EE022190 : ‘!.î : FLTD    F2,R2

FC160CF8 : ED9F8104 : .Ŵflí : LDFD    F0,&FC160D10

FC160CFC : EE031190 : ‘..î : FLTD    F3,R1
C Library 6.09 (06 Feb 2021)

There must be a list of Shared C Library function entry points somewhere, which would make it possible to work out what functions are being called.

What are you using to read the code? Zap (rick-06 or later) is capable of recognising programs that use CLib and annotating with function names.

Here’s a short example (I’ve removed the opcode data to save space):

00009080 : BL      &0001FCAC          ; call: strstr
00009084 : CMP     R0,#0
00009088 : MOVNE   R1,R8
0000908C : ADDNE   R0,R13,#&028C      ; =652
00009090 : MOVNE   R2,#&40            ; ="@"
00009094 : BLNE    &0001FC7C          ; call: strncpy
00009098 : ADD     R0,R13,#&0C        ; =12
0000909C : ADR     R1,&000091E0       ; -> string: "notice"
000090A0 : BL      &0001FCAC          ; call: strstr
000090A4 : CMP     R0,#0
000090A8 : BEQ     &000090D0
000090AC : MOV     R1,R7
000090B0 : ADD     R0,R13,#&020C      ; =524
000090B4 : MOV     R2,#&7F            ; =127
000090B8 : BL      &0001FC7C          ; call: strncpy
000090BC : ADD     R0,R13,#&020C      ; =524
000090C0 : BL      &0001FCBC          ; call: strlen
000090C4 : ADD     R1,R13,#&020C      ; =524

That code is difftime. Running the compiler in assembler output mode generates this:

                  difftime
000000  e2202102          EOR      a3,a1,#&80000000
000004  e2211102          EOR      a2,a2,#&80000000
000008  ee022190          FLTD     f2,a3
00000c  ed9f8104          LDFD     f0,[pc, #L000024-.-8]
000010  ee031190          FLTD     f3,a2
000014  ee022180          ADFD     f2,f2,f0
000018  ee033180          ADFD     f3,f3,f0
00001c  ee220183          SUFD     f0,f2,f3
000020  e1a0f00e          MOV      pc,lr
                  L000024
000024  41e00000          DCFD    2147483648.0
000028  00000000

How such a simple looking function turns into that….makes my head hurt.

Thanks, all. I discovered this lot at the same time as you!

Except the bit about Zap – I’ve been using rick-07 for ages, but the comment option (which I didn’t know existed) was turned off. So, thanks for that!

Given that time_t is an unsigned int (under RISC OS and POSIX), and this is a simple subtraction, why on earth is it promoting everything to double?

Because that’s what difftime() is defined to return, possibly for compatibility with other platforms where time_t might be something other than an integer count of seconds? Dunno.

I have to admit that I don’t even begin to understand Martin Avison’s dump above.

So: difftime subtracts two 32-bit integers and returns the result as a double. What combination of input values can cause an invalid operation?

While I was painting this morning NH had…

11:41:27.44 ** Error **
  Error  : &80000020
  Message: Divide by zero
Divide by zero
Postmortem requested
cc84 in anonymous function
14284 in anonymous function
  Arg2: 0x00013a5c 80476 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe24dcf8f]
  Arg1: 0x000216b8 136888 -> [0x77654e3c 0x756f4873 0x4424646e 0x2e3e7269]
fc151630 in shared library function
83b4 in anonymous function

I had a closer look at NH Syslog, and noticed that normally there is something like

14 Apr 12:15:16 140 >>> DATE
14 Apr 12:15:16 140 <<< 111 20210414111516
14 Apr 12:15:16 140 Date: 210414 111516

Some thoughts about the FP errors – DaveH has said he has done nothing in that area … but anyway I am having problems with v1.52-32. However, the incidence seems to have increased – I cannot remember seeing such problems in the years I have been using NH to fetch every 15 minutes. But they seem associated with date/time calculations, and one thing which has changed is the date/time, and I wonder if it has increased to a value which is causing more of these problems?

when it has a problem that run obviously ends with just the DATE request

Is it a problem with parsing the date? Have date strings changed at all (other than switching to summer time)? Is something perhaps using a timezone name rather than hour offset?

There was nothing in *Where and no OS dump, but NH had vanished from the iconbar!

Divide by zero isn’t an exception. It’s a maths error that could be trapped using signal(), but given the indeterminate state afterwards, it’s usually better to sanitise values to avoid the problem in the first place; e.g. if you’re dividing something by something else that you are not absolutely sure cannot be zero, check it before the division. And if you are sure the value cannot be zero…check it anyway.

What you see looks like a generic handler that basically does “oh crap, this is bad, let’s just spew some nerdy gibberish and then abort”.
Of course, having function names would help track down where it’s going wrong… :-p

Of course, having function names would help track down where it’s going wrong… :-p

Builds since yesterday have function names.

Divide by zero

Where I’ve been able to find floating point division used, I’ve observed that a check for zero was already in place, along with appropriate correction.

Re. DATE – the NewsHound Help file states that DATE isn’t part of the NNTP RFCs, and is not supported by all servers. I can’t add any personal insight into that. NewsHound can be configured to ignore the error if it requests DATE but doesn’t get it, and supposedly gets the time from the computer’s clock. Again, not tested because the servers I use do support DATE and it has never gone wrong for me.

Since I’ve found and fixed some more bugs since the test version that went out, I’m now convinced that the best way forward is to try the current version rather than do any more reverse engineering on the obviously defective version. I’ll send one out to people who’re having trouble.

Where I’ve been able to find floating point division used

I have a feeling (having run into this myself with a faulty integer percentage counter (got the amount and size back to front)), that this may be any division by zero, not just FP ops.

one thing which has changed is the date/time, and I wonder if it has increased to a value which is causing more of these problems?

If so, we’d all be seeing the same problems.

Seems to be a bad day for me: After returning from a walk, I found an error box with
Error block: 80000001 Internal error: abort on instruction fetch at &60000010
from an unknown task … but when I cleared it NH had vanished from the iconbar!
However, I do have an annotated dump, which mentions…

R14 = fc237054 = FPEmulator +4324 = Fix_Numeric +74
      Function call to fc2358c0 = FPEmulator +2b90 = RoundNum_Extended +0
...
R14_usr = 0000cc50 = +4c50 in application memory
          Function call to fc160cec = SharedCLibrary +139f4 = difftime +0

Builds since yesterday have function names.

Is that the CLib in ROOL ROM builds, or yours?

I’ll send one out to people who’re having trouble.

That would be fine, thanks.

Hmm…

CLib entry #9: x$divtest (internal function)
This function is used by the C compiler to test for division by zero when the result of the division is discarded.
If R0 is non-zero the function simply returns. Otherwise it generates a Divide by zero error.

Is that the CLib in ROOL ROM builds, or yours?

My builds of NewsHound.

I hadn’t twigged until Martin emailed me just now, but he’s having these problems with a NewsHound RunImage from over 10 years ago! Long before I started interfering with it.

So the problems are not new.

That puts a different slant on possible solutions.

If its from 10 years ago and there could be all sorts of dogginess on recent machines.

I’ve found a lot of software which worked up to the Pi4 and then had issues, many due to bodged 32 bit conversions i.e. put a 32 bit header on the file, and just leave all the 26 bit only code as is.