ZeroPain: Failed to write log file : Size limit reached

If ZeroPain records a bad event caused by YOUR software,

Uh…?

I thought that was the point of ZeroPain? To record bad events? Or is my software so crap that I never saw the message “Everything worked perfectly, I’m so proud of you” in the logfile?

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

Because it’s more fun to Up Up Down Down Left Right Left Right B A!

if ZeroPain raises issues

Implied cause of the issues being zeropain

If ZeroPain records a bad event caused

Explicitly stating what caused the issues (and it wasn’t ZeroPain)

Hi all

Thank you to clarify why ZeroPain is usefull regarding the so common NULL pointer dereferening.

Make sense then to activate ZeroPain logging when debugging my own softwares… and desactivate NetFetch/Hermes during the debugging session :)

Cheers

Make sense then to activate ZeroPain logging when debugging my own softwares… and desactivate NetFetch/Hermes during the debugging session :)

Exactly so.

Starting the ZeroPain module disables the Compatibility page (because it is trapping and emulating).
Stopping the ZeroPain module re-enables the Compatibility page.

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…?

The sequence of events (with the compatibility page) is that the first dereference (of address 0×28 as it happens, since the body pointer isn’t at the start of the ObjectTemplateHeader) “works” in as far as it silently picked up garbage. This is then passed along the chain and eventually ends up being passed to create a new gadget, which then aborts – because the compatibility page has some specially chosen phrases in it which are in themselves duff pointers (so the first dereference returns a junk value, if you try using the junk value somewhere later it’ll fail).

This is an interesting illustration of a class of bug that catches you regardless of high/low vectors. On a Risc PC (whose ARM predates the ability to move them) or Iyonix (say, low vector 5.22 vintage) if you mount a floppy then ADFS copies some code down at address 0×28. Running old WeatherUKs on either of those machines will abort in the same way because an instruction part way through the floppy’s FIQ handler is used as a gadget pointer, and most common ARM instructions aren’t valid pointers.

The good news is, with a couple more rounds of emails with Malcolm, there’s now WeatherUK 1.11 which fixes the problem. Turns out it’s raining today.

Or in brief (I will try) it was broken and people had just not encountered the broken bit purely by luck or not test running on an old enough machine.
A bug is a bug. Which Malcolm has now fixed (with help)
ZeroPain / High Vector 1, excuse system for keeping Low Vector 0.

WeatherUK… Who cares anyway… it rains all the time :)

No offense ;)

Sorry if this question has already been answered.

I’ve been reading this thread, and I’ve become interested. I was wondering, why does some software for RISC OS access the zero page? I mean, why has that been the case in the past, and why does it need to change now?

Usually because of a bug.
Occasionally some naughty software deliberately read one of the values stored in zero page, which it should have obtained by offical means from the OS.
But mainly because of a bug.

No application software should use zero page, and bugs should be fixed, as they may cause other problems (see above!) sooner or later.

Ignoring programs which deliberately access zero page, when creating pointer variables in C/assembler a NULL value (0) is the preferred ‘undefined’ state – it doesn’t have to be 0 but it is by convention. As a consequence pointers get given the value of 0 a lot.

int* p = NULL;

symantically means that p isn’t pointing to anything – but actually its pointing to address 0.

If your programs fails to point p to a ‘defined’ memory location, ie it is NULL, then if you wrote

if (*p == 3 && p != NULL) {do something}

the *p reads the contents of memory location 0 and the hi vector version will fault it. If you wrote

if (p != NULL && *p == 3) {do something}

it would have worked ok in the high vector version.

Neither version is a problem to the lo vector version as the first version isn’t a bug with the lo vector rom as you program will always execute the correct path.

This was a contrived example to show that zero page access doesn’t necessarily cause a bug with your program. The more usual situation is possibly

if (*p == 3) {do something}
    *p = 4;

The first line would result in your program ‘doing something’ depending on the state of an ‘undefined’ memory location, the second line stores a value at an ‘undefined’ address.

Zeropain will let you know if you are dereferencing an ‘undefined’ NULL pointer’ but it won’t do anything for the case where the ‘undefined’ pointer is a freed memory block.

Moral of the story. Always check for NULL pointers, always check for them first and always set freed pointers back to NULL so that you can tell that they are undefined.

Always check for NULL pointers

Yes. Wouldn’t it be nice if the OS did too?

The good news is, with a couple more rounds of emails with Malcolm, there’s now WeatherUK 1.11 which fixes the problem. Turns out it’s raining today.

David also mentioned a similar problem with NewsUK – probably the same code construct and hence a similar fix.