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

Opened 21 months ago

Closed 17 months ago

Last modified 11 months ago

#389 closed bug (fixed)

YAM locks up or crashes when un-iconifying

Reported by: mikesteed Owned by: tboeckel
Priority: high Milestone: YAM 2.9
Component: user interface Version: 2.8p1
Severity: major Keywords:
Cc: OS Platform:
Blocked By: Blocking:
Release Notes:

Enforce disposing of all images if YAM is running on an 8 bit screen (excluding the Workbench) as soon as the image is no longer used. This works around a bug in picture.datatype which seems to keep a pointer to the screen the image was remapped to and accesses it later even if the screen no longer exists.

Description

This problem occurs when runnning YAM on my A3000 with a Cyberstorm Mk III (68060 @ 50 MHz), running under OS 3.9.2 and MUI 3.8. I have the latest version of all the MUI components that YAM uses.

The problem occurs with both YAM 2.8, and with the 19-Feb nightly build. It happens both with the default theme, and with the MagicWB theme that I normally use (with the corrected images per ticket 386). I am running YAM on a MUI custom screen, an 8-bit colormapped Picasso 96 screen.

The problem is that YAM either crashes, or just locks up when un-iconifying. To demonstrate the problem, I just run YAM and wait for it to open its user interface window on the custom MUI screen. I then click the MUI "iconify" gadget in the window border, and wait for the icon to appear on the Workbench screen. I then double-click the icon. The custom screen opens, but the window never does.

Most of the time this lockup is not accompanied by any Cyberguard hits. Sometimes the system seems to still be stable, while other times Workbench or something else crashes later on, and when I reboot I get a flashing red screen until I cycle the power. This suggests that memory has been corrupted.

Occasionally I do get a string of Cyberguard hits -- reads and writes of low memory by exec, the graphics library, and the picture datatype -- similar to what was discussed in ticket 386. It's not clear if these are the cause of the problem, or are just reactions to bad data.

If I tell YAM to restart, which appears to perform the same closing and re-opening of the user interface, there is no problem.

Attachments (1)

YAMCrashLog.txt (3.5 KB) - added by mikesteed 21 months ago.
CyberGuard hits from crash

Download all attachments as: .zip

Change History (15)

comment:1 Changed 21 months ago by damato

  • Milestone set to YAM 2.8p1

As usual, I would propose that you please provide an enforcer hit / cyberguard hit output if available. In addition, please check your AppIcon settings in YAM and try to disable it to see if this solves your problems. Please also check if you remove the "YAM.info" icon from the binary if the problem will be solved. There are good chances that the icon you are currently use show similar problems like with your old MagicWB theme.

comment:2 in reply to: ↑ description Changed 21 months ago by tboeckel

As I stated in #386 already I also experienced these invalid memory accesses from various components like Picasso96, datatypes.library, exec.library/AfAOS. Unfortunately there is absolutely no trace of YAM or of the classes it is using in the stack trace, in contrast to the issue in ticket #386. There TheButton.mcc was included in the stack trace and this finally led me to the true cause. As long as YAM does not occur in the stack trace it will be impossible to fix anything in YAM.

Does the same crash happen with earlier versions of YAM, too?

comment:3 Changed 21 months ago by tboeckel

I did some tests in the meantime and the only way to avoid these invalid accesses is to comment out the final DisposeDTObject() call to eventually release the image. Even if this might fix this issue, this approach will also leave the corresponding image files locked and even worse will cause major memory leaks.

Changed 21 months ago by mikesteed

CyberGuard hits from crash

comment:4 Changed 21 months ago by mikesteed

I've attached a grab from CyberGuard showing the last four hits (there were others earlier that I missed) from one crash. As you noted, there are no hits from within YAM or any of the MUI components.

I have always had the AppIcon setting disabled in YAM. I tried deleting the Workbench icon for YAM (which required running it from a shell), but the same crash occurred when restoring it (I'm using the standard icon that comes with the program).

As noted, the same crash occurs in YAM 2.8. I don't have any earlier versions installed at the moment, and it's a bit of a pain to re-install YAM 2.7, since 2.8 seems to make some changes to the settings that 2.7 doesn't understand, requiring all the settings to be re-done. I'll try to check with 2.7 in the next few days.

comment:5 Changed 21 months ago by tboeckel

I still have not found the true cause of these crashes. For me this happens only if I quit YAM and the images are finally disposed by DisposeDTObject(). Iconifying/uniconifying YAM works perfectly.

As a temporary workaround we could let YAM skip that DisposeDTObject() call under certain circumstances. The drawback would be that YAM would leak some memory and the image files would stay locked as they would not be closed anymore. But this would only cure the crashes upon termination.

comment:6 Changed 21 months ago by mikesteed

I temporarily reinstalled YAM 2.7 from a backup, and confirmed that it has the same problem. Using the 2.7 default theme it locked up when uniconifying. I normally don't iconify YAM, so I had never noticed the problem. I wouldn't have seen it with 2.8 either, except I was investigating some of the other bugs I uncovered.

Oddly, I don't have any problem when quitting YAM- no CyberGuard hits, no crashes, and no system instability. It's only iconifying/uniconifying that causes problems.

I did discover another way to cause the lockup- open the MUI prefs for YAM, then do something that makes YAM close and re-open its user interface. YAM again locks up after re-opening the custom screen, but before opening its window.

comment:7 Changed 21 months ago by tboeckel

Please try again with the next nightly build. I did a small change which made the hits I experienced myself vanish. Perhaps this fixes your issue as well.

comment:8 follow-up: Changed 21 months ago by mikesteed

That works for me, too- YAM no longer crashes or generates CyberGuard hits when uniconifying or when reopening its user interface after a MUI settings change.

It's not totally good, though. When YAM reopens after being uniconified the gray background on the folder and trash icons, as well as the shadow on the status icons, is bright pink instead of gray. And the image in the "about" requester is totally scrambled color-wise. All the other images seem unaffected.

When changing MUI settings (actually, there's no need to change anything- just open the MUI settings requester and then click 'Cancel') the colors are sometimes correct (gray is gray), and sometimes incorrect (gray is pink)- it seems to vary randomly.

You mentioned that the fix might involve a memory leak, and that does seem to be the case. I haven't tried to track it precisely, but just looking at the Workbench memory display (flushing memory before each reading) shows a loss of around 100K every time YAM is quit. If I iconify and restore YAM before quitting then the memory loss goes up to nearly 2M.

Last edited 21 months ago by mikesteed (previous) (diff)

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

Replying to mikesteed:

It's not totally good, though. When YAM reopens after being uniconified the gray background on the folder and trash icons, as well as the shadow on the status icons, is bright pink instead of gray. And the image in the "about" requester is totally scrambled color-wise. All the other images seem unaffected.

Ok, no perfect solution then.

You mentioned that the fix might involve a memory leak, and that does seem to be the case. I haven't tried to track it precisely, but just looking at the Workbench memory display (flushing memory before each reading) shows a loss of around 100K every time YAM is quit. If I iconify and restore YAM before quitting then the memory loss goes up to nearly 2M.

No, this is a different approach without producing memory leaks intentionally.

comment:10 Changed 18 months ago by damato

  • Milestone changed from YAM 2.8p1 to YAM 2.9
  • Priority changed from undecided to high

As this issue seems to require more attention and we are about to release 2.8p1 soonish, we have to reschedule it for the 2.9 release. In addition, as the issue seems to be quite severe it will require more testing to be finalized and thus requires more time.

comment:11 Changed 17 months ago by damato

  • Owner set to tboeckel
  • Status changed from new to assigned

comment:12 Changed 17 months ago by tboeckel

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

(In [6679]) * ImageCache.c: enforce disposing of all images if YAM is running on an 8 bit screen (excluding the Workbench) as soon as the image is no longer used. This works around a bug in picture.datatype which seems to keep a pointer to the screen the image was remapped to and accesses it later even if the screen no longer exists. This closes #389.

comment:13 Changed 17 months ago by tboeckel

  • Release Notes modified (diff)

comment:14 Changed 11 months ago by damato

  • Version changed from nightly build to 2.8p1

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

  • Mike Steed(Reporter, Participant)
  • Thore Böckelmann(Owner, Participant)