[app_server] deadlock on workspace switching

Checked again and this time app_server crashed in WindowLayer::Frontmost() as
in #195.

Ok, it seems i found a way to deadlock it faster,
press Be Menu-Preferences, select all prefs and start them at once.
After they are loaded repeat steps in my first comment after this line:
"After Haiku bootup type in terminal - screensaver."
app_server should lock up after 3-6 seconds.
Hope this would help...

It seems that the more you have opened apps the faster you could dead lock
app_server, i could reproduce this dead lock very easy now, it takes me a
second or two (no more 3-5 min) now to bring down app_server ;-)

back trace for comment #1

I'm afraid I don't understand your description. What should I do with ScreenSaver and Terminal, and how?

Replying to axeld:

I'm afraid I don't understand your description. What should I do with ScreenSaver and Terminal, and how?

Ok, this is just a copy & paste bug from another ticket :-)
You don't need to do anything with ScreenSaver and Terminal now, what you need is:
Boot haiku, BeMenu->Preferences->click.
Select all items in this folder and press enter to load them at once.
After they all loaded you need to start clicking fast on team menu of the Deskbar of just select one of them (e.g. the last one, in my case it's FileTypes) and in the same time you need to start switching workspaces via alt+f1/alt+f2 as fast as you click on FileTypes, after 2-3 sec you will deadlock app_server.
Hope this would help...

That helped, thanks!
Does this still happen after r18646? Even though, I didn't track it back to have anything to do with DesktopSettings (this only happened when I had "Workspaces" open), I can't reproduce it anymore.
(I only see drawing bugs for which I'll open a new bug report)

I managed to reproduce this deadlock only once again, but it might be caused of low memory situation.

A locking deadlock can't really be caused by low memory (unless low memory causes a different code path that exposes a locking bug), so I leave this bug open for now.
Thanks for the update!

This deadlock still with us at r21691.

There was indeed a deadlock in the EventFilter for keyboard events, I changed that recently to process the workspace switch event in the Desktop thread, so it should be fixed for good. The event filter tried to lock the desktop to switch workspaces, but the desktop could already be locked itself and trying to grab the event dispatcher lock... deadlock.

I could still deadlock it with r22510 under vmware, reopening.

Oh and strange thing is that Time & Date preflet still running, but i can't move any window and interface is not responding at all, but clock arrows are still moving.

Can you still reproduce this with r22614? At least I've fixed a few deadlock situations there.
The Time&Date thing is really strange, though - that sounds like a different kind of deadlock.

Replying to axeld:

Can you still reproduce this with r22614? At least I've fixed a few deadlock situations there.
The Time&Date thing is really strange, though - that sounds like a different kind of deadlock.

I could reproduce that thing too, but by creating a new project with BeIDE. The GUI was all frozen, except the mouse pointer (which, AFAIK, is moved from another thread).

diver, can you still reproduce the deadlock when switching workspaces? I think I have fixed a deadlock when using the keyboard shortcuts to switch workspaces, while Axel later fixed some more that affected workspace switching with the mouse, if I understand correctly.

While investigating #634, I have switched workspaces like mad all afternoon. I have not once experienced a lockup (running in VMWare). If there is another way to produce this, than by opening all apps at once and quickly switching workspaces at the same time either by keyboard shortcut or via the Workspaces applet (mouse), then please reopen...

I tried the same with r22730 and managed to deadlock it twice.
Strange but cursor in Terminal still blinks and i see ProcessController activity in Deskbar, but in the same time i can't move any window and system is not responding to mouse/keyboard events. I would like to reopen this bug as there are still some problems remain.

Just to be sure, by "I tried the same" you mean the way to reproduce this I outlined above?

Yes, i mean that i could reproduce it the way i describe it above.

Still here in r23879

Is this bug still with us? I gave it a shot to reproduce it quickly but I had not luck.
Do you still reproduce it in the same way?