Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#177 closed bug (invalid)

Dopus5 + Odyssey = Freeze

Reported by: fearofthedrunk@… Owned by:
Priority: normal Milestone: 4.0-2015R2
Component: Window.mui Version: 4.0-2015R1
Severity: minor Keywords:
Cc: OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

Summary

For a while i have been unable to run Odyssey and Dopus5 at the same time, if they run at the same time and odyssey is active the system freeze. I have noticed that it seems to be muimaster.library that causes it.

Steps to reproduce

1.Start Odyssey
2.Start Dopus5
3.Activate Odyssey

Expected results

No system freeze

Actual results

System freeze

Regression

Notes

Attachments (6)

MUI-4.0-r4303-os4.lha (3.3 MB) - added by Thore Böckelmann 5 years ago.
MUI 4.0 r4303 AmigaOS4
MUI-4.0-r4210-os4.lha (3.3 MB) - added by Thore Böckelmann 5 years ago.
MUI 4.0 r4210 AmigaOS4
dopusmuicrash.txt (4.0 KB) - added by Mikael Rantanen 5 years ago.
serial debug log.
MUI-4.0-r4135-os4.lha (3.3 MB) - added by Thore Böckelmann 5 years ago.
MUI 4.0 r4135 AmigaOS4
MUI-4.0-r4123-os4.lha (3.3 MB) - added by Thore Böckelmann 5 years ago.
MUI 4.0 r4123 AmigaOS4 before FreeWheel patch
MUI-4.0-r4124-os4.lha (3.3 MB) - added by Thore Böckelmann 5 years ago.
MUI 4.0 r4124 AmigaOS4 after FreeWheel patch

Change History (16)

comment:1 Changed 5 years ago by Thore Böckelmann

Status: newpending

Are you sure this is the intended sequence? DOpus should be started first, because it implants lots of patches. If a patched function has been used before and the patch more or less fundamentally changes the behaviour of the original function then anything can happen. It may even be a bug in Odyssey and not related to MUI at all. Did you check other MUI applications?

comment:2 Changed 5 years ago by Mikael Rantanen

Hi!

It doesn't matter in what sequence it's done because the result is the same, when the mui window is activated at the same time as dopus5 is running you get a freeze.
It's ofcourse not possible for me to say that mui is to blame, i'm just a layman.
But it should be eighter mui or Dopus5. Earlier releases of MUI did not trigger this behavior and mui is rapidly developed so i tested to report here first.

today i have tested more mui applications and they all seems to be affected.
SnapIt, NoWinED, Wookiechat, mui prefs… so sorry for draging Odyssey into this.

comment:3 Changed 5 years ago by Thore Böckelmann

Is there anything on the serial line which might help to find the cause of the freeze?

There are 367 revision steps in the SVN repository between 2014R5 (r4117) and 2015R1 (r4484). If MUI should be the guilty part here this means that the revision which causes the freezes can be found with no more than 9 versions to test. Since I don't have DOpus5 running myself fixing this issue demands your help by testing these interim versions. After each test you will have to tell me whether the freeze occurs or not. Depeding on your report I will provide a new version from either a previous or a later revision.

Changed 5 years ago by Thore Böckelmann

Attachment: MUI-4.0-r4303-os4.lha added

MUI 4.0 r4303 AmigaOS4

comment:4 Changed 5 years ago by Thore Böckelmann

Please try r4303. Note that this represents the development state from the time back then which means that things might behave differently compared to the release versions. I am only interested in the fact if the freeze occurs or not.

comment:5 Changed 5 years ago by Mikael Rantanen

Good idea to test version by version until we find out where it stoped working. R4303 freezes the system too so please give me an older one.

I don't have serial communication atm but i will try to set it up. Last time i tested the serial port it seemed to be broken but i will give it another try when i find the required parts.
kas1e seems to be back in the game and he should know dopus5 pretty good so i will check with him if he have any clues.

Changed 5 years ago by Thore Böckelmann

Attachment: MUI-4.0-r4210-os4.lha added

MUI 4.0 r4210 AmigaOS4

comment:6 Changed 5 years ago by Thore Böckelmann

Please try r4210 next.

Changed 5 years ago by Mikael Rantanen

Attachment: dopusmuicrash.txt added

serial debug log.

comment:7 Changed 5 years ago by Mikael Rantanen

I still get a freeze. The serial debug log i got points to a dopus process, thats all i can see.
This is my first ever serial debug log so have mercy on me if i did something wrong :).

comment:8 in reply to:  7 Changed 5 years ago by Thore Böckelmann

Replying to thesmf:

I still get a freeze. The serial debug log i got points to a dopus process, thats all i can see.

Well, as long as nothing points to MUI or any of its classes it is quite unprobable that MUI is the guilty part here. Unprobable, although not impossible.

Are you sure there were definitely no freezes with 2014R5?

Last edited 5 years ago by Thore Böckelmann (previous) (diff)

Changed 5 years ago by Thore Böckelmann

Attachment: MUI-4.0-r4135-os4.lha added

MUI 4.0 r4135 AmigaOS4

Changed 5 years ago by Thore Böckelmann

Attachment: MUI-4.0-r4123-os4.lha added

MUI 4.0 r4123 AmigaOS4 before FreeWheel patch

Changed 5 years ago by Thore Böckelmann

Attachment: MUI-4.0-r4124-os4.lha added

MUI 4.0 r4124 AmigaOS4 after FreeWheel patch

comment:9 Changed 5 years ago by Thore Böckelmann

Component: muimaster.libraryWindow.mui
Milestone: 4.0-2015R2
Priority: undecidednormal
Resolution: invalid
Status: pendingclosed

After a look at the DOpus5 source I think I found the reason for the freeze.

On the one hand I did this change to MUI:

2014-11-04 Thore Böckelmann <tboeckel@gmx.de>

  * Window.c: integrated support of the 3rd party MuiWheel custom class to let
    that darn FreeWheel patch ignore all MUI windows. Unfortunately FreeWheel
    feeds too many input events to the system upon using the wheel which then
    in turn get misinterpreted by MUI as wheel AND cursor key events and for
    example cause all list objects to scroll and change the active item in one
    step. This is definitely wrong and unintuitive.

On the other hand this is the code of DOpus' L_GetWindowID() function where you log points to:

ULONG LIBFUNC L_GetWindowID(REG(a0, struct Window *window))
{
	WindowID *id;

	// Valid window?
	if (!window) return WINDOW_UNKNOWN;

	// Get ID pointer
	if (!(id=(WindowID *)window->UserData) || id<(WindowID *)0x1000 || TypeOfMem(id)==0)
		return WINDOW_UNKNOWN;

	// Check ID is valid
	if (id->magic!=WINDOW_MAGIC || id->window!=window) return WINDOW_UNKNOWN;

	// Return ID code
	return id->window_id;
}

DOpus5 falsely assumes that it is allowed to read and interpret the UserData field of any window, even of ones it did not open itself. This is definitely a bug in DOpus and must be fixed there. You might argue that the support for FreeWheel is relevant for AmigaOS3 and could be left out for AmigaOS4, but even then DOpus is still buggy. An application can set the UserData field to anything it likes, be it valid pointers, prime numbers, your birthday or a clingon opera. That's why this field is named "UserData" and "PublicDataForAnybody".

Feel free to check r4123 and r4124. r4123 will work while r4124 will cause the freeze. For me the case is closed here. Please reopen the ticket if I am wrong.

comment:10 Changed 5 years ago by Mikael Rantanen

Great support, thanks :) I'll try to poke the dopus5 guys and see if they can fix something. Both MUI & Dopus5 is essential to me and many others.

Note: See TracTickets for help on using tickets.