Opened 2 months ago

Last modified 7 weeks ago

#431 new bug

System freeze when dragging the address field in Odyssey 1.23

Reported by: Gregor Owned by:
Priority: undecided Milestone: future release
Component: undefined Version: 5.0-2019R4
Severity: minor Keywords:
Cc: Roman Kargin OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:



System freeze when dragging accidentally the address field in Odyssey 1.23. This can happen when trying to copy and paste text from/to the address field. The problem is also present in Odyssey 1.23-R5 beta01, 02, 03 and 04.

Steps to reproduce

  1. Move the mouse pointer to the leftmost end of the address field in Odyssey, so that the pointer still stays as a text pointer (vertical bar).
  2. Press the left mouse button and keep it down.
  3. Move the mouse toward right, until the pointer freezes.

Freeze is 100% reproducible in my system.

Expected results

Dragging the address field should not even be possible.

Actual results

The address field is dragged, after which the system freezes (mouse/keyboard do not react any more).


Hardware reset is needed.


Tested in AmigaOne X5000/20 with AmigaOS 4.1 Prerelease (resail version, no beta), max RAM amount.

Attachments (1)

muimaster_locking.lha (1.1 MB) - added by Thore Böckelmann 7 weeks ago.
muimaster.library with extended locking selection

Download all attachments as: .zip

Change History (25)

comment:1 Changed 2 months ago by Thore Böckelmann

Cc: Roman Kargin added

I just tried the latest beta 04 of Odyssey 1.23 but I cannot reproduce this issue on my fs-uae based OS4 emulation. At least dragging the address bar with the default "about:" URL works perfectly for me.

Roman, what about you? Can you reproduce this issue?

comment:2 Changed 2 months ago by Roman Kargin

Gregor wrote to me before as well, and I wasn't able to reproduce the issue. I tried again now and still can't. I can move a mouse pointer to the beginning of the address bar, pressing on the left mouse button and move drag bar everywhere I wish without lockups.

Maybe Gregor has some specific MUI-settings… Or maybe something with AISS installation, because when you drag to the areas you can't pointer images changes, maybe if AISS has broken something there…

Can you make a video of a bug? Also, can you try first to go to MUI-settings from Odyssey window, clicking on MUI's settings button and choice "preset: AmigaOS4", so it will use default MUI settings, and try to reproduce your issue.

Also why you say that "Dragging the address field should not even be possible." That done so you can move it to the hot-links and drop it here, to add a current address from the address bar to hot links.

But we need a video so we can see exactly where you move and on which point it freezes. Maybe it crashes when you move it off the screen… Video surely will help.

Last edited 2 months ago by Roman Kargin (previous) (diff)

comment:3 Changed 2 months ago by Thore Böckelmann

@Gregor does drag'n'drop work in general for you? Can you drag any of the background/color/frame settings in MUI prefs?

Last edited 2 months ago by Thore Böckelmann (previous) (diff)

comment:4 Changed 2 months ago by Gregor

@Thore @Roman
If I have in Odyssey "Settings/Mui…/DRag&Dro/Autostart" 'on' (ticked), I can drag the "quick link" buttons, and the objects in MUI prefs, and all these cause the same type of freezing. Also, trying to drag in YAM 2.7 an attachment file to a disk shows this issue.

But I think I found the primary source of this problem! There seems to be a conflict with the latest version (53.29) of "Clock" from the A-Eon's Enhancer package. I use it constantly on my WB screen, in the analog form (with arms).

If I a) close the clock or b) change the form from analog to digital or c) use the previous version (53.20) without changing any settings, I cannot anymore reproduce any of those freezings. The original Hyperion Clock (53.1) does not cause any problems, either.

If you have the Enhancer Software, could you please open the v. 53.29 Clock in analog form and see whether you can then reproduce the issue?

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

I neither do own the enhancer package nor will I buy it, hence I cannot check that version of the Clock tool.

I suppose you have compositing activated on the screens you are using MUI applications on. In that case MUI should already detect that no screen locking is required for drag'n'drop. This locking formerly was required to pause screen updates of other applications while MUI draws the dragged images anywhere on the screen. But with compositing MUI can use a semi-transparent layer and locking the screen is no longer necessary.

However, you might want to try to set ENV:mui/nolock to any content. This will force MUI to skip any kind of screen locking and . If this hack causes drag'n'drop to work even with the new Clock version then both application try to do the same thing in parallel and hence cause a deadlock. Additionally it might happen that MUI does not restore the the screen imagery correctly when dragging the object accros the Clock window. You have been warned.

comment:6 Changed 2 months ago by Gregor

Where do you activate the compositing for WB screen? I use all my Mui programs on WB.

The trick with 'nolock' works! By using it there is no freezing with the new Clock version.

But what is the next step to take? Is this a 'bug' in the Clock or Mui or both? Should I report this to A-Eon and ask them to fix something in the Clock…?

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

The question is: why does the Clock tool need a global screen lock to update its clock face? MUI does require it because it might draw the drag image anywhere on the screen during drag'n'drop actions, at least outside its own window. The Clock tool should draw within its own window only, at least from my understanding of how to draw a clock…

From my point of view this should be reported to A-Eon. At least former versions of Clock did not require this lock. So why does the current version require it?

comment:8 in reply to:  6 Changed 2 months ago by Thore Böckelmann

Replying to Gregor:

Where do you activate the compositing for WB screen? I use all my Mui programs on WB.

That should be GUI prefs → Effects → Visual effects

comment:9 Changed 2 months ago by Gregor

Activating the compositing works also - no freezes!

I reported this issue in an Enhancer bug thread in, with a link to this ticket.

Thank you very much for your help !-)

comment:10 Changed 7 weeks ago by Andy Broad

Hi I am investigating this from the A-Eon end so to speak.

I can confirm the bug occurs when clock is running on a non compositing screen and a drag of the clipboard frame in MUI settings is started. It does not occur when the X-Dock clock.dockapp is running instead (uses same clock.gadget for rendering the clock)

What do you mean by a "global screen lock" ? I would guess at one of


but Clock does none of these. Nor as far as I can see does clock.gadget

comment:11 Changed 7 weeks ago by Thore Böckelmann

Locking the screen either happens via layers/LockLayers() or via intuition/LockScreen(), depending on what is required in certain situations. For drag'n'drop operations LockLayers() should be used on non-composited screens.

comment:12 Changed 7 weeks ago by Andy Broad

OK so which is MUI using?

Clock is not calling any of the above and not doing any direct rendering.

But as I say the crash only occurs whilts it's running. I've disabled the timer loop that updates the hands so no rendering should be taking place and the crash still occurs!

comment:13 Changed 7 weeks ago by Andy Broad

Actually I only disabled the rendering trigger by the timer, if I get rid of the timer itself, then the lockup goes. Investigating further…

comment:14 Changed 7 weeks ago by Thore Böckelmann

I just checked again. For drag'n'drop actions LockLayers() is used on non-composited screens, when using Numeric buttons LockScreen() will be used. I don't remember why different locking mechanisms are used, but I think it made a difference back then.

comment:15 Changed 7 weeks ago by Andy Broad

OK that's interesting. LockLayers() in the case I'm testing then I would guess.

I have now tracked down the exact line of code that 'locks up' at the Clock end. And it's a peculiar one:

SetGadgetAttrs ((struct Gadget *)OBJ(OBJ_CLOCK), window,NULL,GA_HintInfo,buffer_HintInfo, TAG_END);

This updates the date and time info which is displayed using the gadget help tooltip.

Will check the clock.gadget to see if it's doing anythin odd with that tag.

Last edited 7 weeks ago by Andy Broad (previous) (diff)

comment:16 Changed 7 weeks ago by Andy Broad

OK finding s so far at my end:

Clock runs a Timer loop that updates both the display and the hintinfo once a second.

The display is updated with a SetAttrs() RefreshGList() combination (don't ask me why I didn't write this) this doesn't lockup, the HintInfo is updated with a SetGadgetAttrs() call. This is the point that locks up.

Debugging the clock.gadget I see that afer the call to SetGadgetAttrs() the OM_SET method procedes up to a GM_RENDER call and locks up at this point. I replaced that with a more modern DoRender() call but still get the lock up.

I haven't debugged the GM_RENDER to see if there is anything odd in that yet.

By comparison if I drag an icon on workbench Clock pauses at the SetGadgetAttrs() point and the OM_SET method is not called till after the mouse is released and no lockup occurs.

At this stage I can work arround the problem by changing the SetGadgetAttrs() to a SetAttrs() thus avoiding the embedded GM_RENDER call. But this is only a work arround IMHO

comment:17 Changed 7 weeks ago by Thore Böckelmann

Does GM_RENDER any screen locking internally? If yes, how? Via LockLayer() or via LockScreen()?

comment:18 Changed 7 weeks ago by Thore Böckelmann

And if GM_RENDER causes any screen locking, the question is: why?

MUI does require the lock, because it will render the drag image anywhere on the screen during drag'n'drop operations, at least it might render it outside the application's own window. That is the only reason for the lock: to not interfere with graphics updates of other applications which correctly render inside their own windows.

comment:19 Changed 7 weeks ago by Thore Böckelmann

In 6550:

  • masterpop.c: extended the forced screen locking mechanism to choose the kind of locking. This refs #431.

Changed 7 weeks ago by Thore Böckelmann

Attachment: muimaster_locking.lha added

muimaster.library with extended locking selection

comment:20 Changed 7 weeks ago by Thore Böckelmann

You might want to try the version of muimaster.library with extended locking selection.

Set ENV:muiscreenlock to "intuition" to force locking via LockScreen().
Set ENV:muiscreenlock to "layers" to force locking via LockLayers().
Set ENV:muiscreenlock to "off" to force no locking at all.

comment:21 Changed 7 weeks ago by Andy Broad

The render method is very simple, just blit from a backing store into the provided rastport, no locking of any kind.

However, further debugging shows that GM_RENDER is never actually called, the systems locks at the call to DoRender() or if I replace the old style code at the call to ObtainGIRPort() (so proably locking at the equiavalent call to ObtainGIRPort() inside DoRender() I suppose).

Thanks for the updated MUImaster. Testing with this I get lockups with both 'layers' and 'intuition' but naturally not with 'off'.

comment:22 Changed 7 weeks ago by Thore Böckelmann

Testing with this I get lockups with both 'layers' and 'intuition' but naturally not with 'off'.

That's really bad. LockScreen() is documented to be the "intuition friendly" way.

comment:23 Changed 7 weeks ago by Andy Broad

ObtainGIRPort() has a call to LockLayerRom() so I'm guessing this is where it hangs at my end. It will wait there till MUI releases it's ScreenLock if I understand it, so it could be useful to work out where MUI is hanging.

There is nothing on serial to suggest a crash as such.

LockScreen() is supposed to intuition friendly, but you are still limited on intuition calls IIRC, don't know exactly which are safe and which not though.

Workbench uses LockScreen() these days for icon dragging and causes no lockup.

WRT to the Clock program, I will implement the "workarround" anyway as it saves a gratuitous redraw of the gadget.

comment:24 Changed 7 weeks ago by Andy Broad

I have the feeling that any application that displays a gadget update independantly of users input, eg via timer or notification of some kind will potentially cause this lockup (except perhaps MUI based apps).

I tested with Tunenet and if you play a song so that the VUs or the song progress bar are updating then initiate a MUI drag it will lockup.

If you open USBInspector go to the functionailty tab start a MUI drag and drop then insert or remove a USB stick it will also lockup.

Note: See TracTickets for help on using tickets.