ZeroPain: Failed to write log file : Size limit reached

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.

Well spotted!

On the Titanium my test piece, !Store, which pains on start up does now start up without a crash without the ZeroPain module with the current ROM, 06-Apr-18. Reverting to a high vector RC5, 13-Jul-17, without ZeroPain the crash does happen.

ZeroPain’s ReadMe/txt has this, “ZeroPain traps most attempts to read page zero and emulates the operation, providing a safe level of compatibility with the old memory map”. It rather looks as if this has found its way into the ROMs.

The only function of the ZeroPain module would be to log the events.

Another answer to the original question would be to remove the ZeroPain module.

is there any documentation?

Something will have been in the cvs change logs, but I missed it or failed to understand.

Again from ZeroPain’s ReadMe/txt, “Since relocating zero page is very beneficial to the stability and security of the OS, the goal is to have the feature enabled for all future stable releases, starting with RISC OS 5.24”.

It looks as if ROOL has only gone and done it

isn’t this close to the best possible outcome as we go towards 5.24?

Yes, but…

There is stuff out there that still requires a low vector ROM, Sunfish for example.

I can’t find out how to get back to the original “crash” option any more.

See https://www.riscosopen.org/wiki/documentation/show/OS_Memory%2020 for how to turn Compatibility mode on and off.

Also see https://www.riscosopen.org/forum/forums/11/topics/9460 for some clarification of the 3 modes of operation.

Thanks… I thought that I’d seen something, but clearly didn’t manage to find the correct search terms to jog my memory!

There is stuff out there that still requires a low vector ROM, Sunfish for example.

It does? Sunfish runs happily on this high-vector ROM, and has done since I went over to high-vector in 2015.

There is stuff out there that still requires a low vector ROM, Sunfish for example.

As Steve correctly said, the latest version of Sunfish runs without problems with high-vector configuration.

Are there any examples of software NOT working with ZeroPain or the new “compatibility page” configuration, but working with low-vector? The only pieces of software I know of that (understandably!) had problems with this were Aemulor and ADFFS. So if someone has examples – please name them.

It does?

It does!

Sunfish runs happily on this high-vector ROM, and has done since I went over to high-vector in 2015.

It fishes OK but menu operations can sink it.

There is stuff out there that still requires a low vector ROM, Sunfish for example.

It does? Sunfish runs happily on this high-vector ROM, and has done since I went over to high-vector in 2015.

Last compiled info from cp15 site: “Version 2.05 22-May-10” – are you on that or the Chris Gransden patch version from 2013? (just a RunImage drop in)
Plus is David Pitt using the standard release from 2010 and seeing a problem that was solved in 2013 but “not relevant” because he runs a low vector OS?

Edit:

It fishes OK but menu operations can sink it.

IIRC that was the bit that Chris fixed.

Sunfish crash.

https://www.riscosopen.org/forum/forums/4/topics/9811

So if someone has examples – please name them.

[…]

Sunfish crash.

I think we’re getting mixed up between different things and different modes of behaviour.

To take the Sunfish crash, it is obvious why looking at the log. The faulty instruction is LDRB R3,[R2,#18] at the point where R2 = 00000000. This is clearly an error in Sunfish as it shouldn’t be loading anything from &0 plus 18… Sounds to me like a pointer into a struct that hasn’t been allocated, but that’s just a guess.

Without ZeroPain and with the compatibility page (which a seriously hope is the boot up default), these problems should “magically disappear”. They’re still there, of course, but the effects will be the same as for previous (low vector) ROMs.

There should be very few programs that require high or low vectors. Steffen has named the only two I can think of. Any other failures will be due to bugs, and this is why I hope compatibility mode is the default unless something says otherwise. Leave things looking and feeling as before in as much as Is possible.

Since relocating zero page is very beneficial to the stability and security of the OS,

I never entirely figured out why moving a lump of read only memory was so beneficial when there are such glaring issues as…the entire RMA… I get the “freedom to twiddle the OS vars in page zero” bit, but since that’s not exactly been publicly documented….. Software ought to be using the API, not poking around in system workspace.

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.

Yes, the developers who are still maintaining their software have been outstanding in this respect, and there’s no doubt that huge numbers of bugs have been addressed.

However where does this leave the software that isn’t being actively maintained? I would imagine there is just as much of this around as there is fixed software.
Hell, just the other day I had to turn alignment exceptions off in order to run something that was just updated to be “compatible with the Iyonix” (I don’t remember what or I’d name it). That’s what I meant by naïve – not the active developers, but all the programs still being used but no longer maintained.

I don’t think it is a problem.

Me neither, not if compatibility mode is the default setting.
I get what Andrew is on about. There are some users who just want their machine to work (or work as it did previously), without getting into all the technical stuff. You can argue until you’re blue in the face that programs hitting zero page are broken, but the fact is that all of this brokenness worked before. Maybe it triggered some obscure bugs, but the DDE itself is a great example of a place with lots of pain, yet it was perfectly capable of building RISC OS and all of the many many applications we use daily. That’s what I mean when I say there are users who just want stuff to work.

The developers and more geeky users can then choose to enable pain logging for testing and developing, much as they do now.

And I pretty much doubt anybody will want the Draconian option. ;-)

Doing it like that will satisfy everybody. Logging options for us, and the rest can Keep Calm And Carry On Blissfully Unaware.

You can argue until you’re blue in the face that programs hitting zero page are broken, but the fact is that all of this brokenness worked before. Maybe it triggered some obscure bugs,

If I write something that works most of the time but fails as soon as the year changes is that working or broken and in need of a fix?
If I write something that needs to see a server that it doesn’t need to use (but a previous version did) and falls over when the server isn’t there is that working or broken and in need of a fix?

Are there any examples of software NOT working with ZeroPain or the new “compatibility page” configuration, but working with low-vector?

NewsUK     1.28 (11-January-15)
WeatherUK  1.09 (4-April-18)

Both from the PlingStore and same developer.

This was recently raised on csa.apps.

WeatherUK 1.09 (4-April-18)

So, how benign is WeatherUK when running on a low-vector ROM? We reckon it’s calling Window_ExtractGadgetInfo in a way that doesn’t get picked up by the compatibility page, so what exactly does happen when it doesn’t crash…?

So, how benign is WeatherUK when running on a low-vector ROM? … so what exactly does happen when it doesn’t crash…?

Clicking Select on the iconbar icon gets the weather for Ormskirk.

We reckon it’s calling Window_ExtractGadgetInfo in a way that doesn’t get picked up by the compatibility page,

That is rather the point, ZeroPain does not fix everything. From the ZeroPain ReadMe, “Some infrequently used instructions, such as LDRD, are also not dealt with. In these cases a data or prefetch abort will be raised as normal, and the program will most likely terminate with an error”. The key term is “infrequently”.

Clicking Select on the iconbar icon gets the weather for Ormskirk.

As you well know, that wasn’t the question being asked.

That is rather the point, ZeroPain does not fix everything. From the ZeroPain ReadMe, “Some infrequently used instructions, such as LDRD, are also not dealt with. In these cases a data or prefetch abort will be raised as normal, and the program will most likely terminate with an error”. The key term is “infrequently”.

That’s irrelevant with the compatibility page, however, as the documentation of OS_Memory shows that it operates completely differently from ZeroPain. With ZeroPain, there’s no memory there and ZeroPain catches the resulting abort before faking the memory read. With the compatibility page, there is real memory there, and no emulation takes place.

So, the question again: what, exactly is WeatherUK doing that isn’t picked up by having the compatibility page present? Is it trying to read from an address outside of the page which happens to be there with the low vector ROM?

And with a low vector ROM, there’s still the question of what it then goes on to do with the data that has been read. Unless it does nothing, which is why stuff like

if (foo->bar == TRUE && foo != NULL)

can be ignored¹ if there’s a compatibility option in place, are we certain that it doesn’t then go on to attempt to manipulate the window that it’s just failed to look up?

¹ Although I’d still argue that they should be fixed in any future updates to the code.

As you well know, that wasn’t the question being asked.

No. I managed to interpret it as was there any other manifestation of trouble when running with low vectors.

That is rather the point, ZeroPain does not fix everything.

Strange, I got the impression that the point you were trying to make was that there are still people developing items and doing their testing on low vector builds instead of developing items and testing them on high vector.

Clearly if Malcolm had done the latter there wouldn’t even be a problem application for you to point at.
So, to agree with you in one respect, but probably not one you had considered. Sometimes the thing you need to fix is human…

If ZeroPain writes are a concern, couldn’t it be alleviated to some degree by writing the log to a RAMdisk?

This thread reminded me to check my log. Apparently I totally failed to remember ZeroPain exists since last year some time. So, when one builds their own ROM, where would they find an up to date copy of ZeroPain?

I leave my system running for weeks at a time without a reboot sometimes, and it does quite a few ROM builds a day, and is always running other things too. Crashes are pretty much nonexistent. I guess stability without it is getting better.

So, when one builds their own ROM, where would they find an up to date copy of ZeroPain?

It is in the relevant beta ROM downloads, including the Pi ROM downloads, or cvs

The current version is ZeroPain 0.07 (19 Aug 2017).

Hi

I am unable to follow all these technico-philosophical discussions regarding ZeroPain.
So my question is: why would redirecting ZeroPain logs to null: an issue for me if my use of RiscOS is
- office work (word processing, spreadsheets, DTP, etc…)
- emails
- basic internet browsing
- Developping in C with DDE28b: could my programs be impacted by ZeroPain bugs using C with DDE28b?

If my system is stable with the application I use, I guess that I can safely redirect logs to null:

am I right or wrong?

Regards

François

So my question is: why would redirecting ZeroPain logs to null: an issue for me if my use of RiscOS is
- office work (word processing, spreadsheets, DTP, etc…)
- emails
- basic internet browsing
- Developping in C with DDE28b: could my programs be impacted by ZeroPain bugs using C with DDE28b?

If my system is stable with the application I use, I guess that I can safely redirect logs to null:

am I right or wrong?

Both right and wrong :)

If you are a general user then not seeing the ZeroPain logs because you sent them into a digital black hole doesn’t affect you, however if you have some strange behaviour and the developer needs to see any possible logs you don’t have any to show.

So then we come to the developer being you and you want all the log information you can get to find out what went wrong on your last iteration of your code so then you start swearing at yourself for disabling the logging…

f my system is stable with the application I use, I guess that I can safely redirect logs to null:

am I right or wrong?

That is right, the logs can safely be redirected to null:

P.S. As I understand it with OS5.24 the default will be not to log. That functionality is now in the beta OS5.23 and is in use here working just fine, no ZeroPain module, no logs. I expect that will get announced at the time.

I am unable to follow all these technico-philosophical discussions regarding ZeroPain.

The simplest advice I can give is: ZeroPain helps you and other developers to identify and possibly fix buggy software. Inspect the logs it writes regularly and inform other developers if you encounter bugs in their software.

Nobody is perfect, and writing software in C is error-prone. The errors logged via ZeroPain are typical programming errors. It makes no sense to pretend that they are not there.

So my question is: why would redirecting ZeroPain logs to null: an issue for me if my use of RiscOS is
- Developping in C with DDE28b: could my programs be impacted by ZeroPain bugs using C with DDE28b?

The reason that this is such an issue is because NULL pointer dereferencing is so common in C. If you never make mistakes then you don’t need the ZeroPain output, but otherwise the logs can tell you that there’s a bug in your code and also point to where it is.

IMHO, all development and testing should be done on high-vector ROMs with ZeroPain active, because if the developer catches their bugs, the users don’t have to.

Nobody is perfect, and writing software in C is error-prone.

FTFY.

So my question is: why would redirecting ZeroPain logs to null: an issue for me if my use of RiscOS is
- office work (word processing, spreadsheets, DTP, etc…)
- emails
- basic internet browsing

If your software appears to work correctly, then it is “mostly okay” to discard the error reports. There is something wrong, but that wrongness is no less wrong than it has been up until now.

However…

- Developping in C with DDE28b: could my programs be impacted by ZeroPain bugs using C with DDE28b?

This is where ZeroPain is useful. It is fairly typical to group together logical tests of stuff such as:

if ( (message.action != 0) && (message != NULL) )
{
   ...exciting stuff...
}

Makes sense, right? Make sure there’s a message and handle it.

Problem is, if message is NULL, what the hell is message.action pointing at?

This problem is pretty widespread, and I’m sure I’ve made the same mistake a bunch of times.

Also…

mystruct *thingy = NULL;

...

thingy.whatever = BUSY;

If you have complex or convoluted code paths, it isn’t out of the realms of feasibility of addressing an array before it has been passed through malloc()/calloc().
Or maybe crappy code that doesn’t realise that realloc() can fail, and when it does it returns NULL?

As everybody else has said, if ZeroPain raises issues in YOUR software, then something is wrong and that will need to be fixed (with ZeroPain’s log basically handing you a map to where the problem is).

Don’t be offended, you can have zero pain in BASIC and assembler, but the general behaviour of C makes it child’s play to end up with inadvertent amounts of pain. Consider it to be a development aid, not an annoying nanny shouting at you. :-)

As everybody else has said, if ZeroPain raises issues in YOUR software, then something is wrong and that will need to be fixed (with ZeroPain’s log basically handing you a map to where the problem is).

That needs rephrasing.

“If ZeroPain records a bad event caused by YOUR software, then something is wrong and that needs to be fixed (with ZeroPain’s log basically handing you a map to where the problem is).”

Now if someone hands you a free map to lead you out of a maze why would you bury the map?