For the record, the bug has now been diagnosed as checkhandle failing to clear V if the window handle is valid.

Blaming the OS is the last recourse of the scoundrel… but I eventually convinced myself that 2004’s RO4.39 has a catastrophic and reproducible iconbar bug.

I have now downloaded RPCEmu and installed 5.22… and it has the same bug.

Would somebody like to try 5.25? You will have to knock up a tiny task (I will not supply one to avoid any possibility of it being my error).

1. Run a task that creates an icon at -7 with priority 1<<31
2. Run !Alarm
3. Be very alarmed

Would somebody like to try 5.24?

Probably, when it is released. :)

People could try 5.23beta and now 5.25 and likely get the same result.

people could try

The code hasn’t changed in a very long time, it will be wrong everywhere.

Using a priority of 1<<31 seems to be a very bad idea. I’m continuing to investigate.

I won’t be home for another eight hours, else I’d knock up something to test.
(Mom has had an operation, somebody else is taking me in to work, and I run to their cycle, leave an hour early, come back to hours late… Oh well…)

What’s the nature of the catastrophe? Catastrophes that only occur if you do utterly ludicrous and improbable things don’t worry me a lot, unless they actually destroy hardware or wipe my SD card or hard drive…

What’s the nature of the catastrophe?

An entirely sensible question.

Catastrophes that only occur if you do utterly ludicrous and improbable things don’t worry me a lot,

Depends upon the nature. A total system freeze if a program does something that follows the documented API is unacceptable, regardless of how improbable the activity may be. Or the cascading one-task-after-another dies problem. Or…

Some combination of:

• All icons disappear off the iconbar
• Random redrawing of unrelated areas of the screen
• Exception reporting loop
• Random application errors
• Pointer disappearing
• Black screen
• Error on ticker
• Total freeze
• ôflå

Other than that it’s fine.

Priority &8000000 doesn’t appear to be a valid priority going by the Wimp_CreateIcon Iconbar syntax documentation. The highest priority appears to be &70000000 for ADFS HD, above that is probably no mans land!

For a moment – I thought Rick was cycling to Work :-)

regardless of how improbable the activity may be.

Indeed. That’s why I ANDed it with ludicrous – obviously I can screw the system up thoroughly if I do something barmy enough. Who the hell tries to make a priority of 2^31 (or -2^31 if you prefer)? Okay, you could stop that gap, but you can’t stop every gap, especially in a co-operative system.

Priority &8000000 doesn’t appear to be a valid priority

It says “here are some common values”, it does not say “no other values are valid”. There are no described limits, and there’s nothing in the code to suggest there are any magic values or restricted ranges.

Indeed the comparison is signed (and need not have been) so it appears that negative priorities were anticipated…

Who the hell tries to make a priority of 2^31

Me. I do. It would appear to be the lowest priority possible, just as &7FFFFFFF is the highest. If you want your icon to always stay at one end, it would appear to be the correct value to use.

I have now confirmed that &80000001 works fine, but &80000000 causes horrific memory corruption. This is a bug… if a sometimes pretty one:

It would appear to be the lowest priority possible,

Ah, okay. And your reasoning is fair enough too. Bit of a pain to find out the hard way. The documentation could specify a valid range, but a graceful failure when it’s out of range would be nice.

The Wimp header file (https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Wimp/hdr/Wimp?rev=4.10;content-type=text%2Fplain) says:

WimpPriority_Maximum * &78000000

There appears to be no specific minimum [yes, there is, but it’s in a different place – see below], but rather negative values are a bitmap of options decoded in https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Wimp/s/Iconbar?rev=4.10;content-type=text%2Fplain so maybe the problem is any negative value is taken as flags? The value is -2147483648 in decimal and almost all the bits are zero, so we’ll be passing into the code to look for flag bits and eventually falling out with nothing…

Hmmm…

SWIWimp_CreateIcon
   MyEntry "CreateIcon"
   LDR     handle,[userblk]
   CMP     handle,#-8
   BHS     addtoiconbar       ; handle = -1 - -8
   BL      checkhandle_owner  ; check that window is owned!
   BLVC    int_create_icon
   B       ExitWimp

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/Desktop/Wimp/s/Wimp02?rev=4.55#l4074

So where is your icon creation ending up?

If you want your icon to always stay at one end,

Maybe it is worth noting that the top of the iconbar source says:

;; R0 = handle of icon to open next to (if used)
;;      if icon not found, move to extreme left/right of iconbar

So maybe giving a bogus icon handle to open beside will have the desired effect of forcing the extreme left/right side?

No Sir. I said -7, so it goes to addtoiconbar, and for -7 R0 is taken as a priority. No flags.

WimpPriority_Maximum * &78000000

Which implies it’s only a five (four?) bit field. But that’s not how it’s used in the code, so I cite the usual RISC OS it all works by coincidence anyway rule and regard symbols as less informative than the actual code, which uses all 32 bits (the corollary of this rule is that the documentation has merely not been proven to be dead wrong yet – see ReadLineV).

the corollary of this rule is that the documentation has merely not been proven to be dead wrong yet – see ReadLineV

In most cases the documentation tends to reflect the intention rather than the actuality – unless it went through the hands of one of those “technical author” types whose title tends reflect the intention rather than the actuality in which case it bears no resemblance…

Other misnomers: “Technical Implementation Manager” – we have one with that title. Triple failure.

No Sir. I said -7, so it goes to addtoiconbar, and for -7 R0 is taken as a priority. No flags.

Ah, my bad. I thought the &80000000 was the icon flag/priority, I missed the -7. Duh.

Still, looking at the code, I’m just getting stuck on “I have now confirmed that &80000001 works fine, but &80000000 causes horrific memory corruption.” It would be simple if it was “big number taken as a negative, blah blah” but the fact that &80000000 fails while &80000001 works. Why? What’s unusual about &80000000?

So I presume you are now changing one of your tasks from ‘debugging the WIMP’ to ‘rewriting the WIMP in C’ to fix all this ;-)

So I presume you are now changing one of your tasks from ‘debugging the WIMP’ to ‘rewriting the WIMP in C’ to fix all this ;-)

With speed up in processors we probably need something to introduce some less efficient code…

What’s unusual about &80000000?

The two worst problems in programming are:

1. Off by one errors

&80000001 works. Why?

Because it’s not the smallest value.

In the brief time I had available yesterday I knocked up some debugging of the Wimp’s iconbar lists. The resulting lists appear entirely consistent and logical after &80000000 has been added, but the next icon added breaks everything horribly… ooh, let me check something.

What’s unusual about &80000000?

It is probably nothing, but I note that &80000001 is -&7FFFFFFF. Is something assuming a maximum value of &7FFFFFFF, either + or -, leaving &80000000 as an orphan?

* 7FFFFFFF 7FFFFFFF nZCv
  7FFFFFFF 7FFFFFFE nzCv
  7FFFFFFF 00000001 nzCv
  7FFFFFFF 00000000 nzCv
  7FFFFFFF FFFFFFFF NzcV
  7FFFFFFF 80000001 NzcV
  7FFFFFFF 80000000 NzcV

  7FFFFFFE 7FFFFFFF Nzcv
* 7FFFFFFE 7FFFFFFE nZCv
  7FFFFFFE 00000001 nzCv
  7FFFFFFE 00000000 nzCv
  7FFFFFFE FFFFFFFF nzcv
  7FFFFFFE 80000001 NzcV
  7FFFFFFE 80000000 NzcV

  00000001 7FFFFFFF Nzcv
  00000001 7FFFFFFE Nzcv
* 00000001 00000001 nZCv
  00000001 00000000 nzCv
  00000001 FFFFFFFF nzcv
  00000001 80000001 NzcV
  00000001 80000000 NzcV

  00000000 7FFFFFFF Nzcv
  00000000 7FFFFFFE Nzcv
  00000000 00000001 Nzcv
* 00000000 00000000 nZCv
  00000000 FFFFFFFF nzcv
  00000000 80000001 nzcv
  00000000 80000000 NzcV

  FFFFFFFF 7FFFFFFF NzCv
  FFFFFFFF 7FFFFFFE NzCv
  FFFFFFFF 00000001 NzCv
  FFFFFFFF 00000000 NzCv
* FFFFFFFF FFFFFFFF nZCv
  FFFFFFFF 80000001 nzCv
  FFFFFFFF 80000000 nzCv

  80000001 7FFFFFFF nzCV
  80000001 7FFFFFFE nzCV
  80000001 00000001 NzCv
  80000001 00000000 NzCv
  80000001 FFFFFFFF Nzcv
* 80000001 80000001 nZCv
  80000001 80000000 nzCv

  80000000 7FFFFFFF nzCV
  80000000 7FFFFFFE nzCV
  80000000 00000001 nzCV
  80000000 00000000 NzCv
  80000000 FFFFFFFF Nzcv
  80000000 80000001 Nzcv
* 80000000 80000000 nZCv

AHA! (Accidental Partridge).

I’ve solved it, and it’s bad news.

Having placed a 1<<31 icon on the RHS:

1. There’s no problem adding an icon to the LHS… so it is not a problem with the formatting code that acts on the completed lists.

2. There’s no problem with adding an icon to the RHS that has a non-zero priority.

3. Adding an icon with a priority of -1 prevents any further problem.

The problem is triggered by having a 1<<31 priority immediately after a 0 priority in the iconbar lists, and then adding a 0 priority.

The code has been sounding an alarm bell for me since I first looked at it, and I’ve only just realised why. If you’ve ever looked closely at what flags you get as a result of comparisons, you may notice some oddities for the values 0 and &80000000. For completeness, there is a useful table to the right.

The code does a signed comparison – LT – which actually compares the N and V flags. They are the same for “less than”, but whether they are both set or both clear is a bit strange when 0 and &80000000 are concerned.

It is not particularly intuitive (to me) that comparing 0 with &80000001 gives nzcv but comparing 0 with &80000000 gives NzcV.

This is the trigger for the bug.

The comparison works and the code has found the correct insertion point. It then jumps to where it checks the iconbar window handle – the iconbar is created on demand, rather than in advance.

If the iconbar handle is invalid, this routine returns an error which is used as a signal to create the iconbar window on demand.

Unfortunately, if the iconbar handle IS valid this routine preserves the flags which, as we’ve just seen, can under some circumstances have both N AND V set… this is the ACTUAL bug.

Which means that if you have a priority &80000000 icon immediately after a 0 priority icon when inserting a 0 priority icon, the Wimp creates another iconbar.

Disappointment ensues.

Problems will occur with any such comparison – see the table for many examples.

rewriting the WIMP in C’ to fix all this ;-)

One of the first things any cat herder must learn is to stop programmers trying to “fix it with a new one”. Fixing a known bug is not a reason for introducing lots of new unknown ones.

Chris chose this moment to

kicks shin

Gee, thanks.