RC2 - heading towards the finish line

I noticed something odd whilst building an Iyonix today. If I hold SHIFT so I’m at the Supervisor prompt, then type *DESKTOP, I get an Abort @ FC030050 (+10380 in UtilityModule)

I’m not seeing it with RC3 under RPCEmu so it might be specific to the Iyonix build.

I’ve not gone back through any ROM builds as I don’t have any, so I can’t be certain it’s a new issue or something that’s been around for a while.

I’ve tested SHIFT boot/*DESKTOP on the Iyonix with 5.28 and it suffers the same Abort but @ FC02F58C (+E40C in UtilityModule).

I also managed to randomly produce the Abort @ FC030050 with 5.31 when changing the Monitor to DPMS in Configuration/Screen.

To confirm this is a fresh extract of HD4 5.28 on a blank drive, with the 5.31 RC3 InSitu update run on it. And just for good measure, I performed a CMOS reset to rule that out.

Hi Jon,

I can confirm I get the same issues with my Iyonix when dropping in to supervisor at boot with either using the shift or escape keys and then going in to the desktop.

It has 5.28 flashed with 5.29 softload and also RC2 of the latest boot sequence installed.

Update: Abort is &FC02F584 and *where shows it is offset &0000E404 in UtilityModule

I noticed something odd whilst building an Iyonix today. If I hold SHIFT so I’m at the Supervisor prompt, then type *DESKTOP, I get an Abort @ FC030050 (+10380 in UtilityModule)

Thanks for the reports – looks like that one has been lurking since November 2018.

This pending MR should fix it: https://gitlab.riscosopen.org/RiscOS/Sources/Kernel/-/merge_requests/70

Thanks Jeffrey, I’ll retest once it’s made its way into the nightly build.

I’m seeing the Menu 0.41 issue discussed in this bug thread with the Pi 23-04-23 ROM.

Menu 0.41

Depressing isn’t it! At least the RC3 candidate is reverted to Menu 0.40.

Does anyone with a repository account have the necessary permissions to disable it, reverting to the previous one, until it’s fixed?

Does anyone with a repository account have the necessary permissions to disable it, reverting to the previous one, until it’s fixed?

Yes, I can do that here and have been doing so for the last three months. I would prefer not to offer ‘fixed’ builds, it would be better for ROOL to get its act together.

It is easy to do, no account is needed. Download a current ROM source code tarball and remove Menu 0.41, download Menu 0.40 separately and place it in the local source tree, then build as per normal.

With some reluctance it must be said that this state of affairs has gone on for too long. See here and here

This is a paid for bounty failing, ROOL needs to get this sorted. The dev builds are not currently fit for purpose.

I thought Sprow fixed the issue, given my initial testing, and was under the impression he was going to submit the changes back into the master source.

At the time I didn’t check any of the main branch builds for this issue as I assumed Sprow had it in hand…he had after all confirmed it was also an issue for RO5, not just RO3 which I was concerned with.

Perhaps he forgot, or simply missed me confirming the fix was good?

I thought Sprow fixed the issue, given my initial testing, and was under the impression he was going to submit the changes back into the master source.

There are two issues. This is the first for which there may be a fix. Just when things were looking hopeful another issue popped up.

There are two issues

I know. I reported the first and confirm back to Sprow that his fix worked. That somehow got missed or misunderstood so I raised it again and Sprow built some new Modules to test…at which point I spotted the 2nd issue and once again Sprow built some revised Modules that I confirmed resolved both issues.

At this point, I’m unsure if either fix were submitted to the master source as Sprow didn’t come back to confirm – I’m assuming not. Probably best to wait and let him confirm the current state of play.

I know I did test a recent PlingSystem on an A440/1 and it completely broke the machine, so I rolled back to the test Modules Sprow supplied, combined with a really old WindowManager as that’s been an issue for many years…that’s for a different thread though.

Somethings – seem to get missed – like all the work to get USB DOS floppy drives to work -added to RO.

This is the update to Menu 0.41 that upsets menus in OS5. A diff to revert that is :-

--- ADFS::ROOL.$.TiRom.Titanium.RiscOS.Sources.Toolbox.Menu041.c.auxiliary041	2023-04-29 09:13:51.0 +0100
+++ ADFS::ROOL.$.TiRom.Titanium.RiscOS.Sources.Toolbox.Menu041.c.auxiliary	2023-04-29 09:13:51.0 +0100
@@ -375,5 +375,5 @@
 
-   do {
+   while (*(pposition+1) != -1) {
 
-      int_entryb    = menu_internal_entry (menu_intb, *pposition);
+      int_entryb    = menu_internal_entry (menu_intb, *pposition++);
       submenu       = int_entryb->submenu_show;
@@ -403,9 +403,5 @@
          DEBUG debug_output ("a","Menu: found subsidiary\n");
-         if (*(pposition + 1) == -1) {
-            return (global_menu.current == menu_inta) ? TRUE : FALSE;
-         }
- 
          return TRUE;
       }
-   } while (*(pposition++) != -1);
+   }
    return FALSE;

Depressing isn’t it! At least the RC3 candidate is reverted to Menu 0.40.

This is a paid for bounty failing, ROOL needs to pull its finger out and get this sorted. The dev builds are not currently fit for purpose.

I’m sure that ROOL will happily refund you what you’ve paid for them.

The dev builds are just that: dev builds, from the current sources in the (I assume) master branch of the repository. There’s a warning in red against the downloads, and I’m not sure that there’s any guarantee that they will work.

At least the RC3 candidate is reverted to Menu 0.40.

That’s the whole point of having nightly builds and working towards stable releases.

The dev builds are just that: dev builds, from the current sources in the (I assume) master branch of the repository. There’s a warning in red against the downloads, and I’m not sure that there’s any guarantee that they will work.

This issue has been in limbo for three months now, how good is that! Who is going want to try dev builds known to have an issue?

This issue has been in limbo for three months now, how good is that!

If you’re confident it’s that simple then you could always try submitting a pull request for your fix, of course.

submitting a pull request for your fix

Including information on what testing was performed and on what systems.

I think this is where things are coming unstuck – inadequate testing prior to applying changes leading to stuff breaking.

While there is always the risk of this with nightly “cutting edge” builds (we’re the guinea pigs), there have been some things slipping through that really shouldn’t have.

There are two issues

I know. I reported the first and confirm back to Sprow that his fix worked. That somehow got missed or misunderstood so I raised it again and Sprow built some new Modules to test…at which point I spotted the 2nd issue and once again Sprow built some revised Modules that I confirmed resolved both issues.

At this point, I’m unsure if either fix were submitted to the master source as Sprow didn’t come back to confirm – I’m assuming not. Probably best to wait and let him confirm the current state of play.

I did submit my changes for the issue you’d spotted on RISC OS 3.10, they’re in Toolbox 1.60 and tboxlib 0.29 – the information’s all there in plain sight, the current state is but a few mouse clicks away.

There remains a bug in Menu 0.41 introduced on January 7th as part of the ongoing bounty in that area which appears to have been relayed to the hunter 22 days later. Hopefully a fix is in the works. I’ve got plenty of my own bugs to pick from thanks!

It’s entirely normal for a stable release to back out any risky changes or known bugs, I recall EtherUSB had an issue at some point close to the gate closing and so got rolled back. Each stable release typically includes ~600 changes, so experiencing a few bugs along the way still represents a very low defect rate.

int_entryb = menu_internal_entry (menu_intb, *pposition++);

Still one of those things in C/C++ that will be easily done wrong.
it’s correct. Writing it as *(pposition++) helps people like me to make it a bit more obvious.

int_entryb = menu_internal_entry (menu_intb, *pposition++);

Still one of those things in C/C++ that will be easily done wrong.
it’s correct. Writing it as *(pposition++) helps people like me to make it a bit more obvious.

Thanks.

There remains a bug in Menu 0.41

And it still remains to this day.

I can’t (or I won’t) test beta Pi ROMs until the above bug is fixed, because all I have to do is roll over MPro’s Utilities menu entry to see the bug.

What has to be done to get this either fixed or reverted? Is there anything that I can do, or is it (as I suspect) beyond my powers?

    int_entryb = menu_internal_entry (menu_intb, *pposition++);

    Still one of those things in C/C++ that will be easily done wrong.
    it’s correct. Writing it as *(pposition++) helps people like me to make it a bit more obvious.

Sorry, but if you really want it readable, I’d go for

int_entryb = menu_internal_entry (menu_intb, *pposition);
pposition++;

Putting the increment in parentheses, to me, looks more like you expect that to happen before the dereferencing. Of course, if menu_internal_entry has access to the pposition variable that will break it.

(Disclaimer: I regularly do far worse in my code!)

I have been intending to test the Pi 530 release candidate for some time but as yet no candidate has been put together. It looks like RISC OS 5.30 is still some time (many months) away?

Maestro 2.19 in RC3 has issues, see here and here

Maestro 2.18 is good.