Hi

I think I found a bug, a race condition lockup it seems, in the OS4.1 Compositing engine when using MUI in a particular way.

Short story:
First I of course thought it was a fault in the app (which is 68k!) that you can read about in this thread at utilitybase, but because of some wierd results I decided to switch off Compositing in the GUI prefs of OS4.1 and now I cannot reproduce the lockup at all.

Long story:
In certain situations when I open and close MUI windows there is a lockup. Either the entire system appears locked or just the app hangs depending on how I do things. At first the system always just froze when I quit the app but now I can make the system freeze with other tests as well. If only the app hangs the system will hang as soon as I touch the inactive window that was supposed to be closed in the app.

I'm using set(muiwin,MUIA_Window_Open,flag) to open and close windows.

Scenario 1: Locking up the system
Start the app
Open window no.2
Open window no.1
(allow user interaction)
Close window no.2
(allow user interaction)
Close window no.1

Intuition will now lock up and I have to reboot. A warn reboot works, unless I play music through the AC97 chip, then a hardreset is required for some reason.

Scenario 2: Locking up the app
Start the app
Open window no.2
Open window no.1
(allow user interaction)
Open window no.1 (which is already open and will now be made active)
Close window no.2

The app will now lockup within the SetAttr call to close window no.2.

If I touch window no.2 with the mouse the system locks up.
Scout says "Wait intuition" as the status of the app and the sigwait is $00000020. I have never seen "Wait intuition" before. Must be some synchronization with the compostiting engine..?

If I disable the Compositing these freezes are impossible to reproduce.

So how do we proceed with this?

Last edited by Deniil715 on 21-Jan-2009 at 09:16 PM.
Last edited by Deniil715 on 21-Jan-2009 at 05:56 PM.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

Pretty mild interest in this...

Well, let's boil it up a little!

I have figured out what was causing my lockups and created a very small test program (with source) that can recreate the lockup 100% of the times with the right preconditions.

The cause of the lockup is intuition/ActivateWindow executed by a 68k (haven't tried native) program with a task priority lower than 0 (zero) and compositing switch on. ActivateWindow must cause one window become unactive and one window to become active within the same task.

Preconditions:
OS4.1 (tested on A1-XE G4/800MHz, 512MB, Radeon9250/256MB, AC97 sound chip)
Compositing on.
A shell set to a priority of less than 0, for example -5.
Let the test program execute without user-interaction.

The simple way (save all your data first):
Download the test program.
Unarchive to ram:.
Open a shell.
cd ram:
ChangeTaskPri -5
test
Wait until it has finished, if it ever finishes.

The program should be unable to close "window 2", but if you touch it you have a lockup.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

I think AmigaOS4.0 developers; will be interested in your findings.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Deniil715

I had been seeing lockups with my sam440ep with compositing switched on and transparent inactive windows with the ppc version of dopus4 when I opened text files in the text build in text viewer.

Switching off transparency for inactive windows seems to have worked round the problem.

I run dopus4 full screen in clone Workbench mode and with a screen mode of 1280x1024 32-bit.

_________________
Sam440ep 667mhz, 512MB, 120GB 2.5" HD, OS4.1FE
WinUae 3.0.0, OS 3.9, BB3, Catweasel MkIV
Amiga 1200, Blizzard 040/40 (BlizzardPPC 060/200 with SCSI removed at present), mediatorSX pci, Voodoo3, PCI network card os 3.9BB2
4MB Minimig with ARM addon boar

@Dwyloc

Interesting!
Yes, without Compositing off it is impossible to recreate the lockups.

So maybe not only 68k programs are affected, but actually all programs running at a low priority and calling ActivateWindow internally..?!

With my test program it is possible to open Scout after it has locked up if you are careful not to touch window 2 (which is logically closed but still on the screen) and you should see that the task waits for intuition with signal flags $00000020.

Since I realize that the test program doesn't immediately lock up the OS, I want to say that I first tried with a console as window 2, which works asynchronously and therefor when it fails to close my program could still continue to execute and close its window which lead to a lockup when the remaining console window attempted to be activated.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

I downloaded your test program and can't make any lock ups to happen (or any crashes). But I have had strange lock ups every now and then myself. And I'm suspecting it's related to opening windows somehow. The last time I said in amigans.net there's a problem in AOS4.1 I got an answer that there's no bugs in AOS4.1 and that person told me to check my hardware. I've tested my hardware and couldn't find any problems from it. I did even change the battery.

Last edited by Tomppeli on 21-Jan-2009 at 07:54 PM.
Last edited by Tomppeli on 21-Jan-2009 at 07:53 PM.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Deniil715
Just tried your test program on my Sam440, and the app crashed (using task pri of -1), but the OS seemed fine.

P.S. I had not seen this thread before.

Last edited by ChrisH on 21-Jan-2009 at 08:09 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@Deniil715
Does lockup here (A1-XE).

@Deniil715

UPDATE: The first time I tested your program I had 0% transparency set in GUI prefs for inactive windows and I couldn't reproduce your problem. But then I changed that inactive transparency to 10% and now your program can't close its window number 2. Clicking on that window mouse pointer freezes but dockies keeps working.

PS. It's nice somebody found a way how to reproduce these lock ups and I'm not alone with this problem anymore.

Last edited by Tomppeli on 21-Jan-2009 at 08:11 PM.
Last edited by Tomppeli on 21-Jan-2009 at 08:06 PM.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Deniil715
OK, I just recompiled your E-based test program using PortablE (in AmigaE compatibility mode), for both 68k & PPC. I get the same result for both 68k & PPC: The test app crashes when task priority is below 0.

So you can get rid of "+ 68k" from your title!

edit:
@Tomppeli
Ah yes, clicling on that window also freezes OS4 for me too. In fact, a hard reset is required.

Last edited by ChrisH on 21-Jan-2009 at 08:10 PM.
Last edited by ChrisH on 21-Jan-2009 at 08:10 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

In fact, a hard reset is required

Soft reset worked for me.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

Here is the test program as converted to C++ by PortablE & compiled using GCC:
http:/cshandley.co.uk/private/lockupOS4ppc.zip

This includes both OS3 & OS4 versions, and their C++ code.

Use them just like Deniil described.


edit: NOTE: The C++ code may look quite messy, as it was created by PortablE without using the NOPTRTOCHAR switch.

Last edited by ChrisH on 25-Jan-2009 at 10:50 AM.
Last edited by ChrisH on 21-Jan-2009 at 08:19 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@Tomppeli
My Sam440 usually needs a hard reset

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@Tomppeli & ChrisH

I'm so happy you could reproduce it, and on a Sam as well!
I think this may well be the reason for the lockup many (new) Sam user have experienced due to different programs and configurations.

Interesting that it didn't happen with transparency at 0%. This really indicates that there is a problem, probably with communication with the compose.task which I see is new since OS4.1.

I usually have to hard reset if I was playing any sounds or music, but soft reset works most of the time if no sound has been played since boot.

Great (uhm?) to hear that it is a problem also for PPC native apps.

I hope someone picks up on this so we can get rid of it. I have noticed a number of this kinds of lockups seemingly randomly since OS4.1 but I think I can deduce them all to having internally activate windows with a low prio since I test all my apps after compilation at pri -4 from DECH.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@Deniil715

I don't have or know much about OS 4, but this task priority thing could mean that one possible explanation could be that some higher priority task (composer?) in some cases (there's work for it to do) will be TS_READY all the time - maybe calling AttemptSemaphore/AttemptLockLayer.../... in a loop until it succeeds - and if that semaphore is owned by the lower priority task at the moment then that one has no chance to release it as it will not be run until all higher priority tasks are TS_WAIT which doesn't happen.

OTOH it wold be strange to call AttemptSemaphore or similiar in a loop without at least some small time delay in between which would mean that the task would sleep (TS_WAIT, unless very small time delays are implemented as busy loops) for some time giving lower pri tasks chance to run.

@Deniil715

Thanks for all that work in narrowing down the problem. I'll raise a reference to it and hope that one of the Intuition devs can look into it.

@Tomppeli:
That was probably me that blamed your hardware. Sorry if I got it wrong.

_________________
cheers
tony

Hyperion Support Forum: http://forum.hyperion-entertainment.biz/index.php

@Georg

It doesn't appear as anything is busy-looping. Would seem like a blunt bug too, having compose.task run at pri 0 and busy looping when trying for semaphores..?

However, I have noticed failures with the WindowToFront and the composition too. Nothing crashy, rather a window becoming transparent just when I click on a gadget in the window and it isn't active. The window itself always performs a WindowToFront when activated.

Tried to screen grab it but then it refreshed itself..?!

@tonyw

I have been struggling with this for about a week now. I found it during development of TheMPegEncGUI but obviously thought it was a fault in it, then a fault in MUI vs. Composition, but then the minor versions of TheMPegEncGUI worked fine but not the main version so I stipped it to nothing - still hanged. Turned out I tried the minor version in a different shell...

That's when I got the idea that it might be the priorities, especially since The..GUI is multi-threaded too.

Managed to narrow it down to this little test app and ActivateWindow + low priority. Wierd.

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

@tonyw

Quote:

That was probably me that blamed your hardware. Sorry if I got it wrong.

It was somebody else in Amigans.net.

Last edited by Tomppeli on 23-Jan-2009 at 11:42 PM.
Last edited by Tomppeli on 23-Jan-2009 at 11:42 PM.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@Deniil715

I tried running your test program last night but my sam440 did not lockup with ether compositing on or off but now after rereading your original message if may be because I just run your program and did not try to interact with any of the windows.

_________________
Sam440ep 667mhz, 512MB, 120GB 2.5" HD, OS4.1FE
WinUae 3.0.0, OS 3.9, BB3, Catweasel MkIV
Amiga 1200, Blizzard 040/40 (BlizzardPPC 060/200 with SCSI removed at present), mediatorSX pci, Voodoo3, PCI network card os 3.9BB2
4MB Minimig with ARM addon boar

@Tomppeli

I checked last night if I had any programs running with low priority. I had AmiDock priority set to -1. (I think I messed with these priorities when I was trying to find reason to slow booting. The reason for slow booting in the end was I had some big files unnecessarily in envarc. I set everything to 0 pri.

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray