3rd Party Bugs
Pages: 1 2
Dave Higton (1515) 3404 posts |
Not at all. I’m suggesting that, when a null reference is found, all the points along the call path are fixed. |
Dave Higton (1515) 3404 posts |
The nagging worry is what will happen in the case of abandonware. If the source can’t be fixed, and ZeroPain is going to stop providing protection, then that application ceases to be usable. I think that would be bad for the platform. |
Krzysztof Staniorowski (2787) 35 posts |
Fortunately the code is available (at least afaik) so if it’ll be killed on 01/01/2016 then someone might hack it to work until 2026 or so. Still, if the OS has to be broken there should be permanent means to allow people run it “non-broken”.
That might kill the platform (and probably will given that lion’s part of software is old and not always actively supported).
It looks like no one cares it’s broken. I can set up copy of Trac on my server if that would help ;-)
Most likely it’ll be paid :-( |
Steve Pampling (1551) 7921 posts |
If you look at the source you will find that making the simple change to the module to stop it nullifying itself in 2016 is literally as simple as changing 2015 to 2016. It’s arguable whether the change should be any more permanent. |
Steve Fryatt (216) 2044 posts |
That could be tricky for the DDE, given that the source isn’t available to us… |
Gulli (1646) 42 posts |
One could argue that users still hanging on to abandoned software are holding back development of new and supported software. If OS development is being held back in order to keep abandoned software working then that can limit the incentive to develop new applications. |
Malcolm Hussain-Gambles (1596) 811 posts |
Is there a list of software that isn’t compatible….If there really is a nagging worry, surely the best way is to quantify the problem. |
Colin (478) 2433 posts |
But it also stops someone needs to use abandoned software and the latest os for other software. All that will happen here is that, while it is possible – I think the changes are preempting future changes to ARM processors, someone will undo Jeffreys changes so that they can get the best of both worlds prefering to give up zero page protection/high vectors (not sure the reason for the change) which they’ve lived without for years anyway. |
Jeffrey Lee (213) 6046 posts |
There are two main reasons:
Yes, it’s unfortunate that these changes will break lots of software. But it’s not the doom-and-gloom situation that people are making it out to be. Firstly, we (ROOL) haven’t ruled out the possibility of creating a patcher module or maybe some improved version of ZeroPain to allow legacy software to continue to run. Secondly, the source code to ZeroPain is right there and isn’t going to go away any time soon. It’s BSD licensed, so you can do pretty much whatever you want with it, and neither myself or ROOL are likely to try and stop you. In fact we’d probably be more than happy if people were to take the code and improve on it – make the error reports more useful, improve compatibility with software, etc. If anyone is interested in this, I can probably chase down someone at ROOL so that we can come to a consensus on how a ‘proper’ version of ZeroPain should operate – e.g. how best to allow abandonware to continue to run, without hiding bugs in actively maintained software (I’d hope that all software developers – especially professional ones – agree that null pointer dereferences are a bad thing and that it’s better for them to fix their software than forever hide behind a compatibility mode) |
Colin (478) 2433 posts |
Your reasons surprise me. I had thought it was a move forced on you by expected future hardware changes. Given your reasons – which are obvious policy decision and not forced upon you. I admit I was wrong about ZP and it should be disabled on 1st Jan. There is no point prolonging the inevitable. |
Steve Pampling (1551) 7921 posts |
In my view it’s bit of future and a bit of past. Future changes to ARM processors are likely to mean changes to the OS will be required and forcing a controlled change now is useful to avoid a panic later. Past – we already have multi-core processors we can’t use properly and as Jeffrey pointed out sweeping changes required for multithreading etc would be difficult if not impossible if old apps were allowed to carry on with behaviour that was deprecated before Acorn “left” the scene nigh on two decades ago. |
Rick Murray (539) 13385 posts |
Colin:
Stop thinking like a programmer. ZeroPain needs to offer three modes of operation:
It is quite clear that most of us here will likely use ZeroPain in other inert or logging modes. We know our machines, we know our software, and it can be useful for us to track down obscure bugs, since C makes it so damn easy to do null pointer references. Users, on the other hand, will not appreciate software suddenly ceasing working on the changeover day for fixing a problem that may not seem to them to be entirely necessary. We should default to ZeroPain for them being disabled and leave it as an option they can turn on if something they have requires it. As long as the option exists… Remember, the landscape has changed since the heyday of Acorn. There are plenty of alternatives. We need to do what we can to not arbitrarily alienate users. Having said that:
…or a quarter of a century? ;-) So long as there is a “fake it” option, this is a good thing. If our software vomits over itself then we know we have screwed up. Previously, things would have “just worked” but not necessarily correctly. As active developers, we are in a position to do something.
Bugs in module code, yes. For application code, the processor vectors have been read only for a long time. No longer can you stiff a machine by
This one has me torn in two directions. On the one hand, I am going to say that any future incarnation of ZeroPain will need to support commonly accessed locations; but on the other hand any normal1 developer in this century who directly accesses kernel locations instead of using legal API calls deserved to be smacked across the head with my chicken and mayo baguette.
So long as the faker can fake, then make whatever changes are necessary. Any new software should use Proper Ways, so any speed hit or whatever will apply to older lesser (abandoned?) software.
Would the C runtime be able to cope with such a thing?
This is the crucial point. As programmers we are liable to say “meh, crap software deserves to die” (and I’m inclined to agree), but users may not see it that way. If we lose users, that’s not a good thing. Gulli makes a good point with:
The problem is a balancing act. To move forwards but not break (too much of) the past. It’s a both a blessing (we keep existing users happy) and a curse (having to keep existing users happy). ;-) 1 Special exception for people doing deeper level stuff that need data that can’t be accessed by way of a normal API – I suppose when Acorn first designed the API, stuff like Aemulor and ADDFS were unimaginable… |
Malcolm Hussain-Gambles (1596) 811 posts |
Third party software and ZeroPain So one application with problems, guess the author needs to get his finger out… |
Chris Evans (457) 1614 posts |
Unless I’ve really missunderstood things: Please do correct me if I’m wrong. |
Colin (478) 2433 posts |
Rick.
I’m not thinking like a programmer. When I thought they had to do it because they had seen something going to happen in the near future I figured it was stupid to implement this as anything other than a programmers aid until whatever it was actually happened ie put off problems for the users and give developers the tools to fix zero page problems. But that is not the case. This is a policy decision by ROOL taking riscos in another direction and they want to know problems as soon as possible and want everyone to complain about zero page access bugs and hopefully get all the bugs fixed for popular programs that they can. So they need zero pain spitting out reports on as many computers as possible. Basically they want to do something to the OS soon that requires user access to zero page be removed so there is no point in discussing whether it is a good or bad thing and just accept it – the wheels are in motion. As a programmer I’d love to see things move on I can’t say that I use old programs. From a user point of view throwing away RISC OS’s history is a sad day – I’d be livid if a program I liked failed. The program cast aside will be someone’s pride and joy. |
Colin (478) 2433 posts |
Zeropain is required to stop programs which access zero page crashing as the current OS has user access to zero page disabled. As a side effect it spits out reports of programs that are accessing zero page. So disabling/not using it (which will happen on 1st Jan) will cause any program accessing zero page to crash. |
Steve Pampling (1551) 7921 posts |
set the logging path to null: ? |
Colin (478) 2433 posts |
If the solution was simply to leave zeropain running without logging then ROOL would do it. It’s easy enough to do I’ve done it myself for my iyonix – it was adding 1.5min to a 2min rom compilation. They haven’t come to this decision lightly. |
Rick Murray (539) 13385 posts |
Chris:
I’m not sure there is any sensible way to make Zero Page’s location be configurable. It is moving. That much is certain. What I suggest is that ZeroPain (the module) is resident on user’s machines after the new year, but is disabled by default. Therefore any older software that has either not been upgraded or is no longer being developed will crash if it has any of the faults that ZeroPain traps. In this case, the user will have two options. Either accept that the software has “issues” and cease using it, or switch on ZeroPain’s trapping mechanism which will attempt to make the new (page zero somewhere else) build of RISC OS behave like the older (page zero at zero) build. And hence the “faulty” software should continue to work. It is a band-aid, yes. It will, however, help to highlight to users that some of their software may need attention and that it won’t be supported forever. I don’t envisage ZeroPain to continue being in the ROM builds forever; some day it’ll need to go. Perhaps if the multi-core API (or somesuch) breaks a bunch of things, it could happen then? However, for now, there ought to be a “rescue”. Colin:
It caught a facepalmer in one of my programs. Nobody’s perfect. ;-)
I have accepted it. When I was running the Zero Page Moved build1, the biggest offenders were Zap (now fixed) and the DDE itself. I’ve not tried everything, but the machine didn’t blow up. 1 I rely upon CET/CEST working correctly, so I (still) use my older build. One day I’ll catch up, but since unpacking the source takes forever it won’t be today. |
Jon Abbott (1421) 2597 posts |
Totally agree. I had the option to provide a null reference emulation layer for legacy games, but instead chose to bug fix them. At over 60 null references in around 30 games fixed so far, the problem is extremely widespread. Hopefully, in the process I’ll make a few games completable which previously weren’t. |
Chris Hall (132) 3499 posts |
Presuming that here is the place to post ZeroPain error logs, here is one from IGEPv5 running the latest (18-Oct-2015) ROM [which has SmartReflex and ZeroPain implemented] doing a few things like unpacking and compiling a rom. Shared C Library 5.86 (30 Jun 2015) seems to have bugs (nothing new there) as well as LanMan98 2.05 (26 Sep 2010) and MimeMap 0.18 (9 Jun 2015). Hope this helps. |
Martin Avison (27) 1417 posts |
Have you reported them to the author? I think these are all related to LM98 … I understand a fix is underway after I reported them! |
Pages: 1 2