Recoverable Alert on closing a ListTree/NewListTree

Crashlog for the ListTree Collapse Recoverable Alert

Crashlog after that Recoverable Alert and sending/receiving an eMail

I attached a crashlog i get when sending/receiving an eMail AFTER the above mentionend Recoverable Alert.

Again, this is reproduceable

In your ticket report you state that you have used YAM 2.7 to reproduce the problem. Is that really the case or have you used 2.8 instead. If not please try to reproduce with YAM 2.8 and report back.

Argh

Short memory failure, of course this is with the newest 2.8 which were recently released.

Sorry for the mix up

Another crash log, this time coming from MUI

I added another crash log after that Recoverable Alert, this time coming from MUImaster.

Maybe it will shed some light on the issue?

Replying to Raziel:

I added another crash log after that Recoverable Alert, this time coming from MUImaster.

Maybe it will shed some light on the issue?

This crash definitely rings a bell. If the cause is really what I am thinking of, then this is an ancient bug in MUI itself.

Could you please try to reproduce this issue with a debug Exec kernel instead of the normal Exec kernel? A crashlog with a debug Exec kernel should reveal the typical 0xcccccccc value in the CPU register r9 left there by a double Remove() of a node from a list.

Oh yes. I just crosschecked the NList sources and there is definitely a call of MUIM_KillNotify(Obj) in there. The misbehaviour of MUI together with killed notifications and some other very special circumstances was recently discovered during some additions for BetterString.mcc. BetterString already has a workaround for this issue, but NList is still lacking this one.

A temporary workaround would be to disable the automatic scrollbars for NList objects. Set horizontal and vertical scrollbars to "always" on the "Scroll" page of the NListviews MUI prefs. I will try to implement the same workaround in NList as I did in BetterString.

However, a crashlog done with the debug Exec kernel would still be interesting, just to proof that my assumption is correct.

Replying to thboeckel:

However, a crashlog done with the debug Exec kernel would still be interesting, just to proof that my assumption is correct.

I'll try, i have already set kicklayout to use the debug kernel, but it might take a while.
The MUImaster crashlog did take quite some time to show up.

But i can confirm that the Alert comes up the second the scroll bar is drawn (never really realized that, so i believe that you have the bad guy already)

Got one

But it doesn't have the 0xcccccccc in r9 (at least i couldn't find one, but see for yourself).

Muimaster log with kernel.debug

Replying to Raziel:

But it doesn't have the 0xcccccccc in r9 (at least i couldn't find one, but see for yourself).

Of course it does. Look here:

GPR (General Purpose Registers):

0: CCCCCCCC 5981A260 02074F8C 5DE1AB08 02805C78 8042A92B 02973588 8042B704
8: 6FF8F000 CCCCCCCC CCCCCCCC 00000041 48822324 59826284 62829644 00000000

16: 5FB60000 00000000 5981A29C 5981A28C 5E7A0024 5FB60000 49893133 49893131
24: 5981A288 57D69414 6FFFF800 5FB60000 02950000 7F8835B8 5DE1AB08 02973588

This first "CCCCCCCC" in the second line of registers is r9. Hence the problem is exactly what I was thinking of: the old and ancient bug in MUI which I fixed just recently.

But now the bad news. In contrast to BetterString this issue cannot be worked around that easily in NList, because NList constantly adds and removes its scrollbars (if this is enabled by the prefs). Adding the scrollbars means adding notifications, removing the scrollbars means removing the notifications again. And here lies the problem. The workaround for BetterString is to insert a dummy notification right before the one to be possibly removed. For BetterString this works, because the notification will be added/removed only once in the complete object's life time, but not several times. If the same workaround was applied to NList this would result in a constantly growing notification list and hence in a more and more sluggish GUI the more often the scrollbars are removed and readded. This is not acceptable from my point of view.

However, there is some light at the end of the tunnel. At least for AmigaOS4 and possibly for MorphOS as well. For AmigaOS4 (update #6 required) MUI 3.9 will be updated any time soon now via AmiUpdate. Regarding MorphOS, I gave all the necessary informations for a fix to the MorphOS team, but I cannot tell if at all and when they will implement this fix. For the time until the update and especially for MUI 3.8 on AmigaOS3 I can only recommend to use permanently visible scrollbars to avoid this MUI bug.

To make a long story short, I will close this bug as "invalid" as this is neither a bug in YAM nor in NList, but in MUI itself.