Opened 17 months ago

Last modified 5 months ago

#305 new bug

Wrong colors of menus caused by Odyssey

Reported by: Samir Hawamdeh Owned by:
Priority: undecided Milestone: future release
Component: undefined Version: 4.0-2016R1
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

While i browse with Odyssey 1.23 (pratically at random and apparently for no reason) the color of my menu will change

The funny thing is that even the color of the contextmenu of AmigaOS will change aswell (even if no they are not MUI related)

This problem never happen before, however i really don't know since when this problem were introduced (if it was of course)

Steps to reproduce

  1. Just browse the web with Odyssey
  2. At some point this problem with the colors may happen

Notes

My config is:

AmigaOS 4.1 FE
MUI 4.0 2016 R1 (20.6511 svn r5248)
Odyssey 1.23 (latest version with the various patches)

Attachments (3)

top_menu_wrong_color.jpg (916.7 KB) - added by Samir Hawamdeh 17 months ago.
contextmenu_wrong_color.jpg (822.9 KB) - added by Samir Hawamdeh 17 months ago.
FastView_Capture_T170508_184128.jpg (849.3 KB) - added by Samir Hawamdeh 6 months ago.

Change History (12)

Changed 17 months ago by Samir Hawamdeh

Attachment: top_menu_wrong_color.jpg added

Changed 17 months ago by Samir Hawamdeh

Attachment: contextmenu_wrong_color.jpg added

comment:1 in reply to:  description Changed 17 months ago by Thore Böckelmann

Replying to samo79:

The funny thing is that even the color of the contextmenu of AmigaOS will change aswell (even if no they are not MUI related)

I think this is the most important fact. If you manage to archive this effect with any other MUI application than Odyssey, then I would say this is an MUI issue. But Odyssey is known to trash memory. This trashing might cause any kind of funny and annoying effects, random color changes being the most harmless ones.

comment:2 Changed 17 months ago by Samir Hawamdeh

No apparently this specific problem is present only in Odyssey …
Also i never seen this problem using the old binary of OWB (and i tested that browser really a lot) but problem seems started till i've installed one of the recent snapsht of the browser, if i'm not mistake the latest R7 beta posted by kas1e on the amigans.net forum ..

But according to him nothing was changed regarding MUI … so as you say it might be something related to the (trashed) memory … ?

comment:3 in reply to:  2 Changed 17 months ago by Thore Böckelmann

Replying to samo79:

No apparently this specific problem is present only in Odyssey …
Also i never seen this problem using the old binary of OWB (and i tested that browser really a lot) but problem seems started till i've installed one of the recent snapsht of the browser, if i'm not mistake the latest R7 beta posted by kas1e on the amigans.net forum ..

Well, if you say that you updated Odyssey only and the previous version never showed this issue then the conclusion is quite simple, isn't it?

But according to him nothing was changed regarding MUI … so as you say it might be something related to the (trashed) memory … ?

Why should Odyssey's MUI related code require changes to cause issues which become visible within MUI? Memory trashing can happen anywhere within the code.
Please note that all I can do right now is guessing. And Odyssey has been known to trash memory. The latest version just fixes some well known memory trashing bugs, but there is no guarantee that it fixes all of them. On the other hand there is no guarantee that MUI is bug free either. But if just changing from and old to a new Odyssey version causes issues, then it is quite unprobable (although not impossible) that MUI is at fault here.

comment:4 Changed 14 months ago by Thore Böckelmann

Did this strange effect ever happen again yet?

comment:5 Changed 14 months ago by Samir Hawamdeh

Yes it still happen from time to time, however i really don't know how to reproduce ..

Changed 6 months ago by Samir Hawamdeh

comment:6 Changed 6 months ago by Samir Hawamdeh

I don't know .. may be related or not, but i was able to reproduce the color issue again (even if in a different way)

While i have a MUI program opened (Odyssey) i was trying to install Jill:
http://os4depot.net/index.php?function=showfile&file=utility/workbench/jill.lha

However as soon as i have completed the install procedure of Jill a strange azure color appear into the borders of all the other MUI apps opened

My config are:

Sam440 Flex 800 + Radeon 9250
AmigaOS 4.1 Final Edition Update 1
MUI 5.0 nightybuild (svn r5965)

comment:7 Changed 5 months ago by Thore Böckelmann

As usual it is hard (if not impossible) what exactly is causing the messed up colors. It could be anything. I really expect something outside MUI itself, but stilll within a MUI application. If memory is trashed this can affect anything, not just colors. Wrong colors are a quite good and simple manifestation of trashed memory, but the real harm most probably is done somewhere else and much worse than just wrong colors. As just noticed yourself in your initial report even non-MUI applications are affected as well, so the issue is not bound to MUI only.

Since Odyssey is somewhere in the equations all the time I must suspect Odyssey to be the real cause. Its code is complex and even more important it is known to trash memory, at least the old version we still have for AmigaOS4.

So I am affraid I cannot do anything here as I have absolutely nothing to suspect within MUI to behave wrong. MUI is just badly affected just like ContextMenus.

comment:8 in reply to:  7 ; Changed 5 months ago by aros-sg

Replying to Thore Böckelmann:

As usual it is hard (if not impossible) what exactly is causing the messed up colors.

I think memtrash is unlikely, instead almost certainly a case of Obtain(Best)Pen() ↔ ReleasePen() call count mismatch. With bad luck this causes pen to become "free" (even if it is still used and for things like system pens never supposed to become "free") so a following Obtain(Best)Pen() call picks the seeminly unused pens up and modifies color. With (good) luck the pen would not become free (0 usecount), but "only" negative-usecount (== very high usecount), so often a bug like that would be hard to see or to reproduce.

Is MUI 100 % safe that it really never nests or mismatches show/hide setup/cleanup calls? Even in evil situations like something in a show method triggering relayout which triggers hide/show which triggers another relayout. So that it's always show → hide → show → hide and never show → show, or hide → hide, or middle_of_hide → show → hide → after_middle_of_hide. Same for setup/cleanup.
Things like that.

AFAIK there are hardly any rules in MUI developer docs about what custom classes can do in what methods and what not. Like things which can cause relayout. Are they safe to be called in show/hide, draw, handleinput. It is also not explained if or when things are done "inline"/immediately (A) or deferred to main loop (B). For a custom class some things may be safe to do if MUI does it the (A) way, but not if MUI does it the (B) way. Also the other way round some things may only be safe if MUI does it the (B) way, but not if it does it the (A) way. But no docs say if the app is allowed to rely on (A) or (B) behaviour. Or whether there's is a gurantee that MUI in a future version does not switch certain things from behaviour (A) to (B).

MUI is so fragile … so much depends/relies on specific actual internal implementation.

comment:9 in reply to:  8 Changed 5 months ago by Thore Böckelmann

Replying to aros-sg:

Replying to Thore Böckelmann:

As usual it is hard (if not impossible) what exactly is causing the messed up colors.

I think memtrash is unlikely, instead almost certainly a case of Obtain(Best)Pen() ↔ ReleasePen() call count mismatch. With bad luck this causes pen to become "free" (even if it is still used and for things like system pens never supposed to become "free") so a following Obtain(Best)Pen() call picks the seeminly unused pens up and modifies color. With (good) luck the pen would not become free (0 usecount), but "only" negative-usecount (== very high usecount), so often a bug like that would be hard to see or to reproduce.

There is not a single "Obtain(Best)Pen" call in Odyssey. As such I would say that is not the reason. Of course there are lots of such calls in MUI, but since no other MUI application except Odyssey is suffering from similar issues and it is known that non-MUI parts of Odyssey are definitely trashing memory it should it is quite unprobable that MUI itself is causing the issues.

Is MUI 100 % safe that it really never nests or mismatches show/hide setup/cleanup calls? Even in evil situations like something in a show method triggering relayout which triggers hide/show which triggers another relayout. So that it's always show → hide → show → hide and never show → show, or hide → hide, or middle_of_hide → show → hide → after_middle_of_hide. Same for setup/cleanup.
Things like that.

If an application's MUIM_Show method is triggering a relayout, then the application has done something wrong, not MUI. MUI has a strict sequence of MUIM_Setup → MUIM_Show → MUIM_Hide → MUIM_Cleanup and it sticks to this sequence. The only shortcut is a possible failure (i.e. any failed resource allocation) during MUIM_Setup which directly leads to MUIM_Cleanup.

AFAIK there are hardly any rules in MUI developer docs about what custom classes can do in what methods and what not. Like things which can cause relayout. Are they safe to be called in show/hide, draw, handleinput. It is also not explained if or when things are done "inline"/immediately (A) or deferred to main loop (B). For a custom class some things may be safe to do if MUI does it the (A) way, but not if MUI does it the (B) way. Also the other way round some things may only be safe if MUI does it the (B) way, but not if it does it the (A) way. But no docs say if the app is allowed to rely on (A) or (B) behaviour. Or whether there's is a gurantee that MUI in a future version does not switch certain things from behaviour (A) to (B).

I admit there is no really verbose documentation, but there are lots of example applications included in MUI's SDK which perfectly show how to allocate and free resources. The header files explicitly state which structures and which access macros may be used in which state. But it is the application's developer to obey these comments.

MUI is so fragile … so much depends/relies on specific actual internal implementation.

I doubt that. The internal stuff has not changed that much since MUI 3.8. Most of the time, if not all the time, its not MUI's fault, but the applications are buggy. Many developers have become lazy and fail to to check for failure. And even if they do they fail to do the appropriate actions to avoid further failure. If allocating a pen fails the MUIM_Setup method should signal this failure by returning FALSE instead of TRUE. And even if MUI would fail to keep up the required sequence of MUIM_Setup and MUIM_Cleanup and would call MUIM_Cleanup twice with no MUIM_Setup inbetween the application should check if there is anything to clean up at all instead of blindly trying to free a pen twice. This will result in an inconsistent system state as well.

Note: See TracTickets for help on using tickets.