YAM locks up or crashes when un-iconifying

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.

Change History (15)

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.

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.

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.

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.

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.

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.

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.

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.

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.

(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.

Add Comment

This ticket has been modified since you started editing. You should review the
other modifications which have been appended above,
and any conflicts shown in the preview below.
You can nevertheless proceed and submit your changes if you wish so.