ZeroPain the finger of suspicion

I am looking for some advice on reporting ZeroPain issues.

When a ZP error occurs it is sometimes not obvious where the fault lies.

For example, Fred Graute’s Pinboard manager application, !ToggleBD, generates three ZP log file entries when the iconbar icon is Adjust-clicked.

The log shows that the problem is occurring in the Window module on instruction LDR R0,[R4,#0].

A further compication is not knowing if the Window module is the latest version – Module is: Window Object 1.81 (31 Aug 2003)

Is this a problem in !ToggleBD and something I should report to Fred, or is it a system problem and should be reported to the owner of the Window module, which presumably is ROOL?

A further compication is not knowing if the Window module is the latest version – Module is: Window Object 1.81 (31 Aug 2003)

Version 1.81 is ROLs.

ROOLs latest is :-

*help window
==> Help on keyword Window
Module is: Window Object   1.77 (25 Sep 2015)
*

As I understand it the use of ROL’s 32bit Toolbox modules is not supported by ROOL.

!ToggleDB 1.08 is fine here, and painless, with ROOL’s ROM Toolbox Modules.

HTH.

When a ZP error occurs it is sometimes not obvious where the fault lies.

Tell me about it…

The log shows that the problem is occurring in the Window module on instruction LDR R0,[R4,#0].

I can’t speak in this instance, however I find that when a system component throws an error (CLib and MessageTrans are good for this), it is often because they were passed a NULL pointer that they then try to use. As you noted at the top, unwinding what is actually going on can be…interesting.

Module is: Window Object 1.81 (31 Aug 2003)

Not 2013? Mine (from a self-built version of RISC OS that’s from the 5.21 era¹) is 1.73 (27 Jun 2012); so I’d have expected yours to be 2013 at least.

…whuh? where did you get this module? The latest one available in RISC OS 5 appears to be 1.77 → https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Toolbox/Window/VersionNum

[update: just spotted David’s post sent while I was writing this – if you’re using ROLtd modules, know that they won’t be aware of the ZPP changes nor are they ever likely to be updated to be compatible, or updated period…]

Is this a problem in !ToggleBD and something I should report to Fred,

Fred reads these forums, I would imagine he’ll spot this…
…if there’s no reply in a couple of days, contact him directly. Even if it isn’t ToggleBD, it can be useful to a developer to know if problems are happening and when/where.
[update: and now he knows – ZPP RISC OS 5 with ROLtd modules = problem!]

…whuh? where did you get this module?

It’s from ROL’s 32bit Toolbox modules, http://www.riscos.com/ftp_space/generic/index.htm

When the Iyonix really was the Iyonix these were commonly used as they were more developed than the Castle Toolbox modules. They worked very well, it was never a problem at the time. That was then and this is now, ROOL’s versions are the one to use. It looks likes a (painful) flaw has finally been found within this ancient ROL stuff.

As David has already pointed out ToggleBD seems to be ZeroPain free with the ROOL Toolbox modules. The ROL Toolbox modules, although otherwise more advanced, know nothing about ZPP so it’s no wonder they fail.

Even if it isn’t ToggleBD, it can be useful to a developer to know if problems are happening and when/where.

Indeed, now I know that if there’s a ZPP problem with ToggleBD it’s likely due to using the ROL Toolbox (saves me trying to chase it down :-).

however I find that when a system component throws an error (CLib and MessageTrans are good for this), it is often because they were passed a NULL pointer that they then try to use.

The thing is the OS should be checking that the pointer is not NULL, possibly logging an error in a nice system log about the souce of the request with a null pointer and maybe popping up a GUI error report that disappears after a short period.

Thanks to all who replied. I have removed the UnplugTBox file from PreDesk and now ToggleBD runs without ZeroPain entries.
ISTR putting it there when I was using AppBasic so have probably broken something in one of my programs, but for the moent all seems well.