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

#394 closed bug (foreign)

Crash on deleting mail

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

Description

YAM 2.8

I get a reproduceable crash on deleting a mail
(It might happen when or while simultaneously the bottom scrollbar of MUI is drawn and visible, but i'm not sure if this is related)

Two crashlogs showing nearly the same data attached

Normally it's known info mail or spam that gets immediately deleted by me after i scrolled down to the newest mail. (sorted from top - oldest, to bottom - newest)
On doing so and reaching the bottom of the list the bottom scrollbar (right-left) will be drawn by YAM/MUI covering up the formerly newest mail, so i have to scroll down one line again to make the newest mail visible.

Now on deleting this mail the crash happens right after the bottom scrollbar has been erased by YAM/MUI...so i'd say it might be MUI acting up, but i don't know for sure.

AmigaOS4 up tp date with the debug kernel

Attachments (4)

Crashlog_YAM_2013-03-23_00-09-07.txt (37.9 KB) - added by Raziel 18 months ago.
Yesterday crash
Crashlog_YAM_2013-03-24_12-24-06.txt (36.3 KB) - added by Raziel 18 months ago.
and today crash with the nearly exact same data
nlist_20_135.lha (119.5 KB) - added by tboeckel 18 months ago.
NList 20.135
nlistview_19_90.lha (8.2 KB) - added by tboeckel 18 months ago.
NListview 19.90 2nd try

Download all attachments as: .zip

Change History (20)

comment:1 follow-up: Changed 45 years ago by Raziel

  • Status changed from pending to new

comment:2 Changed 45 years ago by Raziel

  • Status changed from pending to new

comment:3 Changed 45 years ago by Raziel

  • Status changed from pending to new

Changed 18 months ago by Raziel

Yesterday crash

Changed 18 months ago by Raziel

and today crash with the nearly exact same data

comment:1 follow-up: Changed 18 months ago by Raziel

I need to add that i have to be quick to make it crash.
Normally on scrolling up and down the list the bottom scroller goes away sooner or later when the listview window rearranges itself.

I *think* that once the bottom scroller is gone the crash won't show up.
I have to test that yet ;-)

comment:2 Changed 18 months ago by tboeckel

  • Component changed from undefined to user interface
  • Milestone set to YAM 2.8p1

Please try to switch off NList's automatic scrollbars. This should fix this issue for the moment.

Changed 18 months ago by tboeckel

NList 20.135

comment:3 in reply to: ↑ 1 Changed 18 months ago by tboeckel

Replying to Raziel:

I just fixed two possible buffer underruns which might have caused trashed memory under certain circumstances. Additionally removing and readding a scrollbar left some old notifications alive and hence let the notification list grow constantly.

What is a bit puzzling is that fact that your crashlogs show the typical 0xcccccccc value in r9 which clearly points to a duplicate Remove() action which was caused by an ancient bug in MUIM_KillNotify. Although MUI on AmigaOS4 is immune to this bug since muimaster.library 20.2346 (you are using 20.2347) it still might be caused by trashed memory.

Please try the attached versions of NList.mcc and NListview.mcc and report back here. I really hope these fix this issue. At least on WinUAE/AmigaOS3 I was not able to reproduce any kind of misbehaviour when definitely occured before.

comment:4 Changed 18 months ago by tboeckel

  • Status changed from new to pending

comment:5 Changed 18 months ago by Raziel

I should have added that im using the debug kernel (which shouldnt be an issue though, just for the record).

I will try the attached versions as soon as possible (which might be as late as beginning of April im afraid (im not at home right now)

Thanks for the fast reply

comment:6 Changed 18 months ago by tboeckel

You did already in your initial report ;) And without the debug kernel this crash wouldn't have happened.

comment:7 Changed 18 months ago by tboeckel

  • Status changed from new to pending

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

I'm testing for some time now and the behaviour hasn't come up again, so i'd say it's been fixed...BUT

the attached .mcc classes seem to have a bug itself..at least i get a strange behaviour, but maybe it's known and fixed already.

If i have a "short" list of mails (say 20) the right scrollbar is VERY small and stuck to the top few centimeters of the scrollbar field...when scrolling down the lsit the little scrollbar gadget moves along but only a little bit so it will always stay in the top few centimeters.

Vice versa with a "long" list of eMails (say 120)...now the scrollbar is nearly filling the whole right scrollbar field and is scrolling down only with the first few eMails before it reaches (because of it's size) the bottom and stays there while the scolling is going on still for a very long while.

This will be partly "fixed" when new mail arrives, but only to be replaced by a half full scrollbar which also scrolls to the top or bottom with many mails and then stays there with still many mails to scroll.

Changed 18 months ago by tboeckel

NListview 19.90 2nd try

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

  • Status changed from new to pending

Replying to Raziel:

the attached .mcc classes seem to have a bug itself..at least i get a strange behaviour, but maybe it's known and fixed already.

The updated NListview.mcc should fix this.

comment:10 Changed 18 months ago by Raziel

Yes it does, thanks a lot :-)

I haven't come across this nasty bug anymore.
I'd say it has been handled ;-)

comment:11 Changed 18 months ago by tboeckel

  • Resolution set to fixed
  • Status changed from new to closed

Ok, closing this one.

comment:12 Changed 15 months ago by damato

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:13 Changed 15 months ago by damato

  • Milestone YAM 2.8p1 deleted
  • Resolution set to foreign
  • Status changed from reopened to closed

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)