close
Comments you submit will be routed for moderation. If you have an account, please log in first.
Modify

Opened 20 months ago

Closed 20 months ago

Last modified 14 months ago

#364 closed bug (invalid)

Recoverable Alert on closing a ListTree/NewListTree

Reported by: Raziel Owned by:
Priority: high Milestone:
Component: user interface Version: 2.8
Severity: major Keywords:
Cc: OS Platform:
Blocked By: Blocking:
Release Notes:

Description

AmigaOS4.1 plus all updates
YAM2.7 release
MUI mcc's at it's latest releases

I have a Mailinglist ListTree set up for my YAM (left side) which consists of the main item "Mailinglists" and five subitems called after the different lists i'm on. (They are AmigaOS4, Digital Universe, ScummVM, YAM and WHDLoad). The last one being the one added today and starting all of it, with four items everything was fine.

Expanding the Mailinglist Tree is working fine, but closing (Collapsing) it summons a Recoverable Yellow Alert which i can click away (after the border of that Alert has "blinked" five times).

Different behaviours happen after this first Recoverable Alert

1) If i receive a mail YAM will *sometimes* crash (no log, sorry)
2) If i close YAM, reopen it and do the Mailinglist example from above again, i get another Recoverable Alert which i can click away, BUT YAM will crash now on exit (log attached)

I know that this recoverable alert appeared before earlier revisions of YAM), but normally only once not repeatable or recreateable.
Now i can...actually every time i expand and collapse that specific tree it Alerts which makes YAM more or less unuseable, i'm afraid :-(

The reason i post it here and not on one of the sourceforge mcc sites is that i don't know which of the mcc's is the culprit (or maybe even at all?) and the log shows YAM crashing, so please excuse the noise and here's hoping for a quick fix.

Attachments (4)

Crashlog_YAM_2012-12-30_14-58-46.txt (35.7 KB) - added by Raziel 20 months ago.
Crashlog for the ListTree Collapse Recoverable Alert
Crashlog_YAM_2012-12-30_20-50-52.txt (32.9 KB) - added by Raziel 20 months ago.
Crashlog after that Recoverable Alert and sending/receiving an eMail
Crashlog_YAM_2013-01-10_15-45-23.txt (38.0 KB) - added by Raziel 20 months ago.
Another crash log, this time coming from MUI
Crashlog_YAM_2013-01-10_20-24-52.txt (38.5 KB) - added by Raziel 20 months ago.
Muimaster log with kernel.debug

Download all attachments as: .zip

Change History (15)

Changed 20 months ago by Raziel

Crashlog for the ListTree Collapse Recoverable Alert

Changed 20 months ago by Raziel

Crashlog after that Recoverable Alert and sending/receiving an eMail

comment:1 Changed 20 months ago by Raziel

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

Again, this is reproduceable

comment:2 Changed 20 months ago by damato

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.

comment:3 Changed 20 months ago by Raziel

Argh :-(

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

Sorry for the mix up

Changed 20 months ago by Raziel

Another crash log, this time coming from MUI

comment:4 follow-up: Changed 20 months ago by Raziel

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

Maybe it will shed some light on the issue?

comment:5 in reply to: ↑ 4 Changed 20 months ago by tboeckel

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.

comment:6 follow-up: Changed 20 months ago by tboeckel

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.

comment:7 in reply to: ↑ 6 Changed 20 months ago by Raziel

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) :-)

comment:8 follow-up: Changed 20 months ago by Raziel

Got one :-)

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

Changed 20 months ago by Raziel

Muimaster log with kernel.debug

comment:9 in reply to: ↑ 8 Changed 20 months ago by tboeckel

  • Component changed from undefined to user interface
  • Milestone set to YAM 2.9
  • Priority changed from undecided to high
  • Resolution set to invalid
  • Status changed from new to closed

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.

comment:10 Changed 19 months ago by damato

  • Milestone changed from YAM 2.9 to YAM 2.8p1

comment:11 Changed 14 months ago by damato

  • Milestone YAM 2.8p1 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • Hubert Maier(Reporter, Participant)