ZeroPain: Failed to write log file : Size limit reached

Hi

I just installed !Reporter, as I am learning to develop for RiscOS.
I am running RiscOS build 5.23, 2-Apr-2018 on Raspberry Pi 3b.
I note that !Reporter reports every second (litteraly) the following message:

ZeroPain: Failed to write log file: Size limit reached

Is there a way to stop these messages occuring in !Reporter, and also stop these write attemps?

Thank you for your help.

UPDATE: I think I have identified the application generating these messages: NetFetch 5.04. The messages start to occur when I ‘Adjust’ click in the icon bar…

I will post a message on the mailing list.

Consequenlty, back on my good ’old ’BeagleBoard-xM!

Regards

François

ZeroPain.ReadMe/txt in the Pi ROM downloads explains how logs are stored.

“ZeroPain will pause logging once the log file exceeds 1MB in size. Deleting the log will allow it to resume.”

Deleting the ZeroPain log, more than once if required, should resolve this.

UPDATE: Until the errant cause of the ZeroPains fills the log up again.

More draconian measures:-

The ZeroPain log can be redirected to a null: device. See !ZeroPain.!Run

Low vector ROM.

Thank you David, I will opt for the draconian measure!

less draconian measures:

Run a fixed version of NetFetch, because I could swear they did a load of zeropain fix work.
Time to contact R-Comp about an update.

I just installed !Reporter, as I am learning to develop for RiscOS.

The ZeroPain log can be redirected to a null: device. See Run

Low vector ROM.

Not really a good set of advice, as having a high vector ROM and ZeroPain is incredibly useful when developing. The combination will highlight (and help you fix) your own mistakes as well as other people’s.

As Steve says, the solution is to talk to R-Comp.

Hi,

I just send a message to Andrew.
In the meantime, how can I redirect ZeroPain messages to null? What line shoud I add in the !Run obay file?

Cheers.

François

In the meantime, how can I redirect ZeroPain messages to null? What line shoud I add in the !Run obay file?

| To specify an alternate log location, add it the end of the line below, e.g.
| 'X RMLoad <Obey$Dir>.ZeroPain ADFS::Foo.$.Bar.Log'
X RMLoad <Obey$Dir>.ZeroPain

As above, just do what the comment says. If you don’t have this !Run file, you probably need a newer version of ZeroPain, which comes with the newer ROM builds.

But, as I said before… the ZeroPain logs are very useful things to have available when developing code.

I note that !Reporter reports every second (litteraly) the following message:
ZeroPain: Failed to write log file: Size limit reached

Apart from the suggestions above, I will add two more…

1. The ZeroPain module is creating the repeated message because the log file it writes to disc has reached it’s size limit (there so it cannot fill discs!). If you delete it, then it will probably create another immediately to write some logs, but the repeated messages will stop. Any new useful log records can be inspected.

2. As you are running a recent ROM, if you stop (ie RMkill) the ZeroPain module, then all logging will also stop. Applications should not be affected (although some may fail if the bugs associated with the illegal memory accesses are severe enough). However, there will be no useful ZeroPain log records.

Full details are in the ReadMe/txt file that is in the ZeroPain directory in the zip file that contained the new ROM.

how can I redirect ZeroPain messages to null?

X RMLoad <Obey$Dir>.ZeroPain null: Tested with !Store, which pains but only one at a time.

But, as I said before… the ZeroPain logs are very useful things to have available when developing code.

Fair point but in this instance the bad is swamping the good.

Fair point but in this instance the bad is swamping the good.

Although, as Martin correctly points out, that’s just because the log file has reached its size limit. The repeated messages to Reporter can be fixed by simply deleting the log file and letting it start to fill up again. There’s no need to remove ZeroPain, divert its logs to null: or switch to a low vector ROM.

The repeated messages to Reporter can be fixed by simply deleting the log file and letting it start to fill up again.

I thought that was what I said!

I thought that was what I said!

I thought that was what I said that you said!

:-)

(Looking at the timings again, David’s post missing this point just crossed yours, so he probably hadn’t it when he posted.)

Communication is a wonderful thing! Just shows how careful writers and readers have to be!

The thing to note is that if, as suspected by François, the culprit is a buggy version of NetFetch then simply not running it should leave the ZeroPain logs clear.

François can then work on development items and Reporter will be showing only the errors/messages that he is interested in looking at.

If the ZeroPain log size limit (of 1MB) has been reached, then the ZeroPain module will pause logging. This means that when the next ZeroPain error is handled, it will not write to the log, BUT it will write a message to Reporter to say the limit has been reached, and queue the log message in memory. The size message will repeat every second until it can write the log to disc – or a reboot wipes memory.

If the disc log is deleted (or renamed) then the module will write up any logs queued in memory to disc (up to 128 I think), and then there will be no more messages. Until the next ZeroPain error anyway!

Therefore, unless you are still running an application which really creates lots of repeated ZP errors, deleting or renaming the disc log file normally stops the repeated size message from the ZeroPain module.

David’s post missing this point just crossed yours, so he probably hadn’t it when he posted.

What are you on about! 🤨

In any case the need for more that one ZeroPain log deletion was in my first post.

Deleting the ZeroPain log, more than once if required, should resolve this.

In any case the need for more that one ZeroPain log deletion was in my first post.

Deleting the ZeroPain log, more than once if required, should resolve this.

Which clears the log but you have to follow the advice from Martin:

Any new useful log records can be inspected.

and then act on the information, like maybe not run the offending item until you have a fixed version or in the situation François has not run it when doing development and wanting to look at logs in Reporter without “noise” fom ZeroPain.

Note: ZeroPain will help give you a stable base to develop on and killing it or ignoring the error logs it produces is a bit foolish if you expect a reproducible error set from your own development.

Hi

Thank you to all of you for your help.
The null trick did the job. Right clicking NetFetch 5.04 does not produce these ZeroPain messages anymore.

One last question: could these many write attempts harm the lifespan of the SD Card. I heard that SD card have a limit in write access and that, with time, they can stop working.

Thank you.

François

The null trick did the job. Right clicking NetFetch 5.04 does not produce these ZeroPain messages anymore.

It does, but you aren’t recording them which is rather different. You need to get a fix to the actual problem.
If you do that and then re-enable ZeroPain you can develop on a stable platform.

Alternately you could do as I suggested and stop running NetFetch (if that is the error source) and develop on a stable platform without the error causing application destabilising things.

My neighbour has a leaky gutter on the side facing my house. I’ve told him and he doesn’t go near that side of the house much now and especially when it rains so he doesn’t see the problem. The side of his house is getting wet and the frosty weather has caused a little ‘spalling’ of the brickwork, but he doesn’t see that either.
Problems don’t go away if you aren’t looking.

Fortunately you’ve e-mailed R-Comp about NetFetch, but that won’t deal with other ZeroPain sources you now can’t see.

Just as a reminder…

Right clicking NetFetch does a fetch using SecureSockets. It’s SecureSockets that does the zero page access generating the error. As far as I’m aware, there is no update available from R-Comp for that module.

Apologies if this is a grandma & egg act.

It is almost certainly not NetFetch itself at fault, but rather the SSL modules that Hermes loads when you right click NF to run Hermes and fetch mail. Hopefully the SSL bounty will help there. If you don’t use SSL, you can simply stop the SSL modules loading by (I think) deleting/renaming them).

(The next bit is something which is causing me severe concern, to the extent of losing sleep and more. Please don’t dismiss it idly).

I would also like to stress this is a non-issue if you run a low vector ROM. I have yet to hear a convincing reason why non-developers would choose to do otherwise. If you’re running the high vector ROM and having problems, ie. seeing ZeroPain logs, I strongly recommend contacting ROOL so that they understand that users are affected by this – 5.24 is in the offing, and it looks like that may be a high-ROM official release – effectively breaking a lot of otherwise-functional software. Jeffrey’s ZeroPain helps a lot (thank goodness!), but is a fix for a problem which non-developer users don’t need to encounter in the first place.

The reason this is an issue for me is that updating older customer machines with (the expected) 5.24 potentially introduces problems for users and hence creates support burden and “your update broke my software/computer” complaints. I can’t in good conscience issue such an update for older systems which have dropped out of warranty and general support. It is easy to forget that most users simply don’t understand the tech side, but ask merely two simple quesions: 1) “How does it make my day-to-day computer usage better?” and 2) “Will any of my software stop working for this benefit?”

I would call on the community to support the release of two versions of 5.24 – low and high vector – with a clear / non-tech explanation to the user of the pros/cons of each. Remember that 5.24 will be the first “stable”/“official” release for Pi and Titanium (ie. not “RC” builds), so this is an important release to get right.

It is almost certainly not NetFetch itself at fault, but rather the SSL modules that Hermes loads when you right click NF to run Hermes and fetch mail.

In which case the second bit of my comment comes into play:

…or in the situation François has not run it when doing development and wanting to look at logs in Reporter without “noise” fom ZeroPain.

If you don’t use SSL, you can simply stop the SSL modules loading by (I think) deleting/renaming them).

I think there are increasingly few situations where SSL isn’t needed so that may not be possible, but worth a try I suppose.

but is a fix for a problem which non-developer users don’t need to encounter in the first place.

That is true, and the idea that users can hassle developers of “broken” software is naïve…

Having said this, why is this a problem? I thought recent(ish) versions of RISC OS essentially offered three options:

• Fault it (programs will abort)
• Fake it (so it’ll feel like low vector)
• Whinge plenty (ZeroPain)

?

Without #2, there will be problems if the official release is high vector…

but is a fix for a problem which non-developer users don’t need to encounter in the first place.

True, Acorn should have shut the door on this and developers would have been discovering the bugs before release. We are where we are and the changes are needed for certain elements of development which Jeffrey, among others, have described before.

That is true, and the idea that users can hassle developers of “broken” software is naïve…

Actually most of the developers were quite grateful for the ZeroPain logging showing where some tricky little program glitches were coming from so they hassled themselves.

Having said this, why is this a problem? I thought recent(ish) versions of RISC OS essentially offered three options:

Fault it (programs will abort)
Fake it (so it’ll feel like low vector)
Whinge plenty (ZeroPain)

I don’t think it is a problem.
Option 1 is no ZeroPain, which a bit draconian but hey perfect software will be fine. Probably.
Option 3 is just a fake through and log – standard ZeroPain
Option 2 is Option 3 with a ditch the log message to null: thus giving no indication anything is wrong and leaving developers mystified about some strange behaviour where the “fake it” isn’t perfect. This isn’t a standard option but stuffing log messages in null: achieves this.

Basically I think you got the list in slightly the wrong order.

Without #2, there will be problems if the official release is high vector…

Deja vu. Read all this back when stable transitioned from 5.20 to 5.22 and the beta 5.23 appeared as high vector.
Mr. Pilling (and some others) spent time fixing things, for free, on programs that people paid for 10-15 years ago¹ and still others argued we needed to be low vector for a while longer. I suggested that we needed the time limited ZeroPain to continue longer.

So, a touch short of three years(from July 2015) down the line we appear to have a longer term ZeroPain with better faking and people are complaining that the faking mechanism reports the reason for the faking action and people like yourself are wondering why the complaints. Me too.

¹ Extremely generous but then many people have nominated him for sainthood over the years.

5.24 is in the offing, and it looks like that may be a high-ROM official release – effectively breaking a lot of otherwise-functional software.

Are you sure about this?

I’ve just tried on a high-vector build from the past week, running the following silly BASIC program:

FOR i% = 0 TO 1023 STEP 4
  PRINT "Reading from !";i%;" = ";!i%
NEXT i%

As you’d expect, with ZeroPain active I get a helpful log telling me that I’m an idiot.

However, with *RMKill ZeroPain and try again, and I see the same numbers returned and no log file. The system doesn’t fall over, either. I suspect that Rick’s correct in stating that recent builds offer three options, although I can’t find out how to get back to the original “crash” option any more.

Is Rick correct, and if so, is there any documentation?

…but is a fix for a problem which non-developer users don’t need to encounter in the first place.

I think you’re wrong. Any decent OS would have faulted NULL pointer reads years ago. A ZeroPain log from a user along with a bug report is a massive help to developers in identifying problems, and as a developer who is benefiting from this change, I find it sad that a major RISC OS company seems to be trying to set users against ROOL in this way.

As far as I can see, with a recent high-vector build:

• Aemulor is OK,

• Buggy software still runs, with the option to turn ZeroPain on and off without flashing a new ROM image, and

• Users have an easy way to generate helpful debug logs for a very common type of error if requested.

If Rick is correct, isn’t this close to the best possible outcome as we go towards 5.24?