YAM crashes when edit window is closed

First of all, the confirmation requester should not appear at all if you didn't modify anything. I just tried to reproduce this issue on WinUAE running AmigaOS 3.9 without luck. Editing a received mail and immediately closing the write window just closes the window, as is to be expected.

Also the hits being caused by TheButton.mcc really make me wonder whether the problem is not located somewhere completely different. This really sounds like trashed memory and TheButton.mcc being a false culprit.

It might be a good idea to redirect the Cyberguard output to a file immediately rather than trying to save it later with an already unstable system.

Finally, please try to reproduce this issue with the latest nightly build (05-Feb-2013). Things might have changed already.

The confirmation requester doesn't appear in the dev. builds, but it does in
the 2.8 release.

I tried the 7-Feb dev. build, and it didn't make any difference. I also tried
capturing the Cyberguard output to a file, and that didn't make any
difference either- the system went down before the file could be written.

So I had to resort to writing the output down by hand and then typing it in
after rebooting. As a result, I only documented one of the two hits (the
other is very similar), and there may be transcription errors.

Here it is:

LONG WRITE to 81811212 PC:0807D54E
USP:0DCD2A6C SR:0000 FLSW:00810200 TCB:0DCD3440
Data:083B7B1C 083B7B28 083B7B28 081F1C94 083A14F4 00000000 083A14F4 08282F34
Addr:81818181 81811212 083A0A40 083A0004 00000000 00000000 08000910 0DCD2A6C
Stck:0825FDF6 00000000 00000000 080145BC 08262BAC 083B7B2C 8042D985 081F1C18
Stck:081F0930 00000000 FFFFFFFF 20000000 083A09B8 083A0A40 0DCD2B14 083A09B8

Hunk 0000 Offset 00000AD6

$0825FDF6 MOVE.L $082595E8.L,A6

Hunk 0000 Offset 0000088C

$08262BAC ADD.L #$4,A7

Name:"YAM_Dev"

This was from the 7-Feb dev. build.

The address of the first long write this time was slightly different than I
saw last time. The second long write was the same, to 81818185. The alert
this time was 81000005 (Memory Corrupt).

Have you tried a different theme already? Although I can confirm the requester asking for confirmation with YAM 2.8 I am unable to make TheBar/TheButton crash anything. Are you using a special theme? Did this crash happen with YAM 2.7 already? What about the demo applications of TheBar?

I normally use the MagicWB_reduced theme. When I switch to the default theme
the crash does not occur, so it seems to be something related to this theme.

This reminded me that there seemed to be a problem when I first tried to use
the MagicWB_reduced theme after installing YAM 2.8- the 'config' folder is
missing from that theme. I tried to fix this by copying the 'config' folder
from the regular MagicWB theme into the MagicWB_reduced theme. This still
didn't work, as YAM seemed to want files with '_big' on the end of the
name. I fixed this by renaming the files.

After this YAM seemed to work with this theme, with all the proper images
appearing in the proper places. But it looks like all is not as well as it
seemed. I can't say I understand how the theme files are organized, so
perhaps I have done something that has fatally confused YAM or TheButton.

Are you using a graphic board or native screens? I get an Enforcer hit whenever I quit YAM after running it on a native screen (i.e. PAL hires/interlaced), no matter which theme was used. Running YAM on a Picasso96/Cybergraphics screen makes no problems. I am running AmigaOS 3.9 on WinUAE. In the end it is picture.datatype writing to an illegal address. If this is the true culprit then there is nothing we can do about this.

I have YAM running on an 8-bit colormapped screen under Picasso 96.

The fact that the system crashes so readily after YAM crashes (especially with any kind of disk activity) suggests that a lot more than just the two long words of memory are getting overwritten. Those two writes are just the ones that get trapped because they're to invalid addresses.

I retract what I said earlier about using the MagicWB_reduced theme- I did start to use that one, but switched to the regular MagicWB theme when I saw that some of the images weren't there, and for those that were the file sizes were identical. I did have to rename the images in the 'config' directory to add the "_big" suffix.

As a test I used MultiView to display every one of the images in the theme on my Workbench screen, which is also 8-bit colormapped. All of them displayed with no problem except toolbar/tb_Config, which drew a "The icon(s) have no default tool(s)" error. That seems to be a DefIcons bug, since renaming the file to "tb_Configg" allowed it to be displayed correctly.

(In [6589]) * resources/themes/MagicWB: corrected the size of some toolbar images. TheBar.mcc requires that normal and disabled images have exactly the same size, otherwise memory will be trashed. This closes #386.

I must add that the fixed images only fix the memory trashing caused by TheButton.mcc. During my tests on my WinUAE/AmigaOS 3.9/AmiKit installation there were other Enforcer hits in different components (picture.datatype, exec.library, intuition.library). Since this is out of the scope of YAM and the classes it is using there is no way for us to fix these issues.

Please get the updated theme images from the next nightly build.

Yet another note. The next version of TheBar.mcc will check the images' dimensions and pop up a warning requester in case anything does not match. The requester will show the affected image's name plus the dimensions.

The nightly build hasn't updated since the 19th, so it doesn't have the new images- perhaps it's not triggered by a change only to one of the 'resources' files?

I grabbed the updated images direct from the source browser and installed them, and can confirm that the crash is gone.