Getting set up with ZeroPain

As a developer I shouldn’t have to ask such basic questions, but I’ve wasted half an hour fiddling around with micro SD cards trying to find a version of the OS for my Raspberry Pi which has zero page protection enabled and a ZeroPain module to allow me to test some potential NULL pointer dereferences. And failed.

What’s the easiest way of getting set up with a reasonably up-to-date RISC OS for Pi3 with zero page protection active?

I was checking for ZPP by opening BASIC in a TaskWindow and trying P.?0

This would be a reliable test, that ought to generate an exception if ZPP is active, shouldn’t it?

Perhaps I mean high vectors rather than zero page protection.

I have found a possible NULL pointer dereference in a module which I want to fix, but I would like to prove it is there by provoking it before I code up a fix.

As standard, RISC OS has a “compatibility page” that fakes the older page zero behaviour (in order that older buggy apps don’t fall over dead because of this OS change).

You’ll need to disable the compatibility page – check the OS_Memory SWI, it’s one of those I think. Then run ZeroPain (which will spot there’s no compatibility page so install itself).

Then you’ll get pain reports if stuff is going wrong.

Here it is: https://www.riscosopen.org/wiki/documentation/show/OS_Memory%2020

From the linked page: If interpreted as a string, the page also contains a message warning the user that a null pointer dereference has occurred.

This is sad, óflå is no longer… 😭

P.?0 generates a ZP log here.
I have the module in Choices.Boot.PreDesk.!ZeroPain
Also in there is a !Run obey containing on one line:
X RMLoad <Obey$Dir>.ZeroPain ADFS::SSD.$.Logs.ZeroPain
as I collect such things in my Logs directory.
If Reporter is running, a ZP error is noted there soon after it happens.

Thank you both for your help. I’ve got it working and verified that the module does try to read from zero page.

I’m not sure how much SWIs are supposed to stop the user doing stupid things. If a SWI has several parameters which are pointers to strings, and the user supplies zero for one of them, should the module trap it and generate an error, or should it just let nature take its course?

See the separate topic for detail on what I am looking at.

should the module trap it and generate an error, or should it just let nature take its course?

Passing zero implies that the user expects it to be interpreted as a blank string, exactly as if it pointed to a zero or a &0D value. Sometimes a blank string would imply a default. If a blank string would be unacceptable then I would expect an error should be returned on the lines of ‘passing R3=0 to SWI &nnnnn is silly’ or ‘passing a blank string in R3 to SWI xxxx is silly’. However if a sensible default exists for a missing parameter, I would use that.

You could make the error message more terse of course as that is much more fun.

You could make the error message more terse of course as that is much more fun.

I can’t help wondering whether all error messages should have a unique token that is actually a reference to an index in the on-line PRMs.

One problem with that is that the page number references are, I think, different from the printed PRMs and the on line PRMs.

One problem with that is that the page number references are, I think, different from the printed PRMs and the on line PRMs.

:)

There was a reason I only referenced the on-line PRMs.
Actually had a list of reasons, but first in my mental list was the variable nature of the page numbering in the hard copy version(s)
Next was that with a cost attached to the hard copy, many users would be looking for on-line info.
Next is that if any particular error doesn’t have a description and remedy then in the on-line info it can be added more easily, and swifter, than any issued addendum or reprint.
Next is that it might be possible to make the reference an active link to the specific section of on-line PRM
If I sit and think a short while I can add more reasons and other people will find many I would probably never think of.

In fact, thinking a little, I’m sure most people would say that a development environment ought to be more than the basic tools to write and compile code. Error identification and help probably ought to be in there.

many users would be looking for on-line info.

If the price was right, and the PRMs documented reality and not something thirty years out of date, then I would be interested in a printed copy. PDFs are great for quick keyword searching, but I find them bloody awful to actually read.

A quick look at Lulu suggests an A5 size book (not sure what the PRM size is, can it be scaled to fit A5?) for 800 pages, printed on regular cream paper (easier on the eyes) with a basic monochrome front and matt finish would cost $18-something per book. Four books ¹, count another twenty five for postage (assuming they’re not sent together), comes to $101 with regular tracked shipping to France. For a one off.

That’s not a ridiculous price. The proper PRMs were not that cheap, remember.

Plus, ROOL has already published, and their printer may offer better pricing, perhaps with a number of presales (to know what sort of numbers to print) so these could be a batch rather than one offs.

Just thinking aloud, but it seems to me that the hardest part of all of this would be knocking the docs into the twenty first century.

Let me know if you want any of that example assembler stuff translated to 32 bit. ;)

¹ I’m ignoring book 5a because logically all that stuff would be folded into the previous books, and there’s a lot of guff in book 1 that relates to the 26 bit world and can be left behind freeing up space for other chapters.

I’m sure most people would say that a development environment ought to be more than the basic tools to write and compile code.

A functional debugger would be nice. :-p

Let me know if you want any of that example assembler stuff translated to 32 bit. ;)

All of it by next Monday please ;)

Just thinking aloud, but it seems to me that the hardest part of all of this would be knocking the docs into the twenty first century.

Hence the bounty.

Hence the bounty.

Except that bounty is primarily about updating the format the content is held in rather than updating the content.

I would suggest that if people did little bits to the on-line info, then that content could be used in the material folded into the bounty project. At this point, the on-line content is an input to the master rather than an output from it.

There’s possibly scope for someone to see what hooks they need in a web page to allow a generated error to link to

Just a small comment – since RISC OS is now primarily a hobby system maintained by volunteers with source code available… can we please terminate with extreme prejudice any notion of “This call is for internal use only” followed by a big blank area.
Everything should be documented. Sure, note if something is only intended to be used by another part of the OS (like the AMB stuff), but then document it anyway.

Such documentation is aimed at developers, yes? These days they’re just as likely to be interested in the OS itself as well as applications for it.

Everything should be documented. Sure, note if something is only intended to be used by another part of the OS (like the AMB stuff), but then document it anyway.

Basically, the documentation is required for others to have a f’n clue how the setup is supposed to work¹. When it doesn’t behave the way it is supposed to, then that is a bug, When it doesn’t behave the way that you expect, but does match the documentation that is a possible development opportunity, or a reason to do what you are doing differently.

But let’s give new (or even existing) developers half a chance of knowing what to expect.

¹ That holds true for any system, application etc. irrespective of OS

the documentation is required for others to have a f’n clue

When you’re faced with… http://www.phlamethrower.co.uk/misc2/ModeChangeSub.png

;)