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

Opened 14 months ago

Closed 14 months ago

Last modified 10 months ago

#386 closed bug (fixed)

YAM crashes when edit window is closed

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

fixed a memory trashing problem where toolbar images of different sizes cause some memory leaks within TheButton.mcc.


This crash occurs when runnning YAM 2.8 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

To cause the crash I pick any item from the inbox mail list, then
click the 'Edit' button. When the edit window opens I click the
window's close box without making any changes. When the "Discard
changes?" requester opens I click 'Discard'. YAM crashes with an
80000008 (privilege violation) error. After this the system becomes
unstable, and other programs are prone to crash as well.

Cyberguard shows a couple of hits prior to the alert, a long-write
to 0x81818181, and a long-write to 81818185. Both come from
TheButton.mcc. Unfortunately, attempts to capture the Cyberguard
output fail because the system crashes before I'm able to save

The same thing happens with the 3-Feb dev. build, except the crash
happens as soon as I click the close box; there is no "Discard
changes?" requester.

Attachments (0)

Change History (12)

comment:1 Changed 44 years ago by mikesteed

  • Status changed from pending to new

comment:1 Changed 14 months ago by tboeckel

  • Milestone set to YAM 2.8p1
  • Status changed from new to pending

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.

comment:2 Changed 14 months ago by mikesteed

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
---->0825FDF6 - "LIBS:mui/TheButton.mcc"
     Hunk 0000 Offset 00000AD6
    $0825FDF6 MOVE.L $082595E8.L,A6
---->08262BAC -  "LIBS:mui/TheButton.mcc"
     Hunk 0000 Offset 0000088C
    $08262BAC ADD.L #$4,A7

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

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

comment:3 Changed 14 months ago by tboeckel

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?

comment:4 Changed 14 months ago by mikesteed

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.

comment:5 Changed 14 months ago by tboeckel

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.

comment:6 Changed 14 months ago by mikesteed

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.

comment:8 Changed 14 months ago by tboeckel

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

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

comment:9 Changed 14 months ago by tboeckel

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.

comment:10 Changed 14 months ago by tboeckel

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.

comment:11 Changed 14 months ago by mikesteed

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.

comment:12 Changed 10 months ago by damato

  • Release Notes modified (diff)

Add Comment

Modify Ticket

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

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)