3rd Party Bugs

Would it be possible to add a 3rd Party Bugs forum on here?

With the amount of big ticket changes going on in RISCOS either in 5.23 or planned for the future, reporting and tracking bugs in 3rd party software is quite important.

Reporting ZeroPain errors is a pain in itself currently, as once you’ve reported it to the author (assuming you can track them down) there’s no visibility in the community.

Providing a forum here would:

1. Allow issues to easily be raised
2. Make the community aware of the issue
3. Allow both the author and community to provide visible feedback and assist in testing / debugging

In my humble opinion that’s a great idea. I wonder why it wasn’t introduced with release of ZeroPain…

I would suggest that a wiki page would be better – rather than trawling through a series of posts, the status of each app could be seen under a heading. IMHO this would be better even than a thread for each app under discussion. Who here believes that it would stick at one thread per app, and who believes that no conflicting information – or pure waffle – would be posted?

OK, I’ve created the page, which is available from Documents → RISC OS user documentation. Only one entry so far – please add and update!

I should add that I was unable to edit the page using the current CI build of NetSurf. I did it with Firefox on Linux. I haven’t been back to try with the last release version of NetSurf.

Does it achieve anything? People have been attributing a zeropain entry to FTPc when it isn’t FTPc’s fault. Just because FTPc highlights OS problems doesn’t make it my problem. Will you keep checking on FTPc to update the page when the error disappears? These problems are not necessarily program specific.

When zeropain is disabled there may be a lot that stops working – lots of unsupported stuff like ROL toolbox modules which may affect a number of programs and everyone who is using norcroft will have to buy a new version to continue programming riscos – assuming they find all of the ‘bugs’.

Given so few people are testing riscos I’m sceptical that the change will be beneficial.

But then I’m always pessimistic.

I use FTPc 1.50 on RO 5.23, with the ZeroPain module loaded. No zeropain problems with uploading, nor with downloading.

I’m hoping that either someone will update the page (it’s a free-for-all, remember), or that someone will post (be it here or another thread) that 1.51 is OK and I (if no-one else) will willingly update the page.

How OS problems will all be found and swept up is a big other question. Any suggestions as to how to organise feedback, fixing and testing?

I guess the bug tracker is key. How to get that fixed?

It’s the nature of the problem that you never know if a program is ok. We’ve have years of development where zero page could be read. All that software will have obscure modes operation which may cause failures for years to come. After zeropain is switched off they will just crash. I understand the reasons for zeropain but I don’t think we have the man hours to implement it quickly.

Yes it gets ‘bugs’ fixed but were the ‘bugs’ really a problem or is fixing them wasting what little programming man hours we have.

After zeropain is switched off they will just crash. I understand the reasons for zeropain but I don’t think we have the man hours to implement it quickly.

This seems like a good time to point out that I still come across software that needs alignment exceptions turned off. If we’re going to stay on the zero pain route, then ZeroPain must remain as a user configurable choice.
I know why this is being done; I’m just not convinced that risking breaking a portion of software that is no longer being actively maintained for a somewhat arbitrary reason (given the lack of memory protection, the third party extensions living and breathing in kernel space, and the inability of the OS to sensibly recover from flaws in modules, etc); I just don’t believe that risking alienating users is the way forward.

So – keep going with the zero page protection, we have to start somewhere it might as well be there. Allocate a CMOS bit to ZeroPain, and bake it into the OS. By all means have it disabled by default. Just don’t decide that on such and such a day everything is going to be switched over, the end.
Reality just doesn’t work like that.

Yes it gets ‘bugs’ fixed but were the ‘bugs’ really a problem or is fixing them wasting what little programming man hours we have.

That depends on what the ‘bugs’ are, I suppose.

So far, I’ve only had a handful (two or three, IIRC) of ZeroPain issues reported to me for my software. Each one, when tracked down, has turned out to be a symptom of an extremely nasty underlying problem that warranted fixing in its own right.

In Locate, the problems came from the code that created a new search dialogue box treating a couple of uninitialised pointers as being valid because it needed the data that would have been there if they were valid (ie. it was doing things in the wrong order). In CashBook, a piece of code turned out to be relying on data that was miraculously still present in freed flex blocks after dialogues had closed.

Both of these nasty problems have now been fixed (in test builds). I would probably have found neither if ZPP hadn’t been implemented, as the other visible symptoms were far too unrepeatable. In both cases, the reads from zero page were really just a side issue from something much deeper.

So no, I don’t think you can dismiss ZPP as a waste of time. It should probably be an option on stable OS releases for now, but I don’t see that running with ZeroPain (and reporting the log results to developers) is a problem for anyone running an unstable release.

I definitely don’t think zero-pain is a waste of time, quite the reverse. I’m not a great programmer, even saying a programmer is possibly over-stating it – however if you take NewsUK as an example.
It has a lot of nasty bugs, which I was unaware of when I wrote it. As time as gone on the bugs have become more evident.
For at least a year after initial release – or maybe longer, there were no symptoms and no problems….
These are detected by zero page, however as I’m in the middle of a re-write of the basic functionality I don’t have time to fix them. If zero page was implemented when I started writing, the bugs would have never happened.
My opinion is that it should be on by default in future stable releases and allow a !Boot plugin to turn it on/off, like the ARM cpu options on the Pi etc.

Given the unnecessary attention zeropain has been given and some of the “blind panic” that has been caused, would it be a good idea to have a list of applications and a ZeroPain OK option – much like the 32bit safe/armv7 OK stuff?
That way at least people have an idea of what has/has not been tested.

I suppose that I should probably add to my last post that by now, I would have expected more progess by ROOL in terms of fixing the DDE and the OS. It’s OK to ask application authors to fix their software by the end of the year(!), but given that deadline I’d expect to be seeing a safe version of the DDE available and visible progress on the OS.

Instead we have tumbleweed and a broken bug tracker. I’m guessing that the DDE fixes – if they arrive – will be in a paid upgrade, too?

So no, I don’t think you can dismiss ZPP as a waste of time.

I don’t disagree that it is an excellent programming tool and well worth keeping just for that. My problem is when you have what seems to be 10 people running zeropain, finding bugs in the software base, even if you can get them fixed, is going to take a long time. This is software that has been running for years without causing a major incident. Is the software better for having been fixed a definite yes. Does the fix ‘really’ affect anyone – I’m not convinced. Zero pain just highlights some bugs.

I’d expect to be seeing a safe version of the DDE available and visible progress on the OS.

ROOL consist of 17 Jeffrey Lees and Sprow and a couple of others all programmers who are probably only using programmers tools. They all have day jobs and hopefully a life so riscos time is minimal. They are relying on us, the zeropain users, to find the bugs for them and preferably tell them how to fix them. The trouble is I’d hazzard a guess then most people running zeropain are programmers who are all using the same programs so the OS isn’t getting a good testing. In the best case scenario for the OS they would be inundated with zeropain reports that would show plenty of people were testing but they wouldn’t have the time to go through them all.

I would have expected more progess by ROOL in terms of fixing the DDE and the OS

I trust they’ll also see sense and provide a free upgrade for all previous purchasers and not charge for a bug fix upgrade.

The trouble is I’d hazzard a guess then most people running zeropain are programmers who are all using the same programs so the OS isn’t getting a good testing.

I started testing under it this past weekend and have already uncovered seven potential issues, some being game specific. It will take years to iron out all the issues in the OS, which is why I believe we need a better way of tracking and discussing them.

It will take years to iron out all the issues in the OS

Perhaps we need to start with better validation of input. To not accept NULL pointers and come unstuck when trying to do something with them…

I’m hoping that either someone will update the page (it’s a free-for-all, remember), or that someone will post (be it here or another thread) that 1.51 is OK and I (if no-one else) will willingly update the page.

I have updated the third party page

!FTPc 1.51 itself does seem pain free, and is even more pain free with an updated Menu module, but the caveat below always applies.

It’s the nature of the problem that you never know if a program is ok.

This is interesting. From a naive point of view, both FTPc and Menu could be wrong!

Is FTPc passing a null pointer to Menu?

Defensive programming suggests that apps should not pass null pointers to anything else when such pointers should not be null; AND lower levels, like menu, should test for null pointers and react appropriately.

The page I created is for third party applications. Should there be a similar page for components of RISC OS?

And thank you, David, for updating the page. Has anyone else any reports to offer about any other applications?

Is FTPc passing a null pointer to Menu?

No.

From a naive point of view, both FTPc and Menu could be wrong!

It is difficult to apportion blame but ATM the FPTc developer believes the issue to be with the module. I cannot contradict that. To pin the matter down further either another Menu pain from another application needs to be captured or ROOL might agree there is an issue with Menu and fix it.

Should there be a similar page for components of RISC OS?

I did start an entry for the Menu module but then the meaning of ‘third party’ sank in. Without too much enthusiasm it did occur that the compatibility page might do with an extra column but that could be seriously fatiguing.

It is difficult to apportion blame but ATM the FPTc developer believes the issue to be with the module

I think “the FTPc developer” even pointed out the specific part of the module where a change is required and what the change should be.

Like many of the instances likely to occur at least part of the answer is contained in the comment Rick made

Perhaps we need to start with better validation of input. To not accept NULL pointers and come unstuck when trying to do something with them…

this is encapsulated and extended in Daves comment

Defensive programming suggests that apps should not pass null pointers to anything else when such pointers should not be null; AND lower levels, like menu, should test for null pointers and react appropriately.

The issue occurs elsewhere – various portions of the Filer module can be accessed via a keyboard shortcut with little modification of the code. However those portions assume that the calling code will check to ensure that there is a valid parameter being passed i.e. that things like using the shortcut without having identified a file/directory to operate on have been done. We already had a keyboard shortcut related zeropain error that demonstrated this.

So is the path to fix the OS weaknesses, to fix the apps that currently exist that hit those weaknesses, or to fix both?

So is the path to fix the OS weaknesses, to fix the apps that currently exist that hit those weaknesses, or to fix both?

Both. It’s the fail-safe solution.

I’ve created a page, similar to the Third Party Applications page, for system components. I’ve added an entry for Menu 0.38.

I’m working from memory here, and I’m nowhere near a RISC OS machine, so can someone please check whether my entry is correct, and edit it if it’s not? Thanks.

Both. It’s the fail-safe solution.

Lets be realistic here it’s never going to happen. Defensive programming is a philosopy that needs to be carried out from the inception of the project not added on later. You’re basically advocating a rewrite of all software and the OS.