[app_server] deadlock on workspace switching

[diver]

This is hard to reproduce i fear, but i'll try to explain. This is kinda stress test and takes about 3-5 min. After Haiku bootup type in terminal - screensaver. You need to switch workspaces (alt+f1,alt+f2) like crazy and in the same time you need to switch betwen terminal and screensaver from in the team menu of the deskbar. You couls see various things, like some menus opening in the upper left corner, white spaces, etc. After several minutes app_server will just freeze.

[diver]

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

[diver]

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...

[diver]

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 ;-)

[diver]

back trace for comment #1

[axeld]

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

[diver]

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...

[axeld]

That helped, thanks! Does this still happen after hrev18646? 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)

[diver]

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

[axeld]

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!

[diver]

This deadlock still with us at hrev21691.

[stippi]

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.

[diver]

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

[diver]

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.

[axeld]

Can you still reproduce this with hrev22614? 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.

[jackburton]

Replying to axeld:

Can you still reproduce this with hrev22614? 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).

[stippi]

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.

[stippi]

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...

[diver]

I tried the same with hrev22730 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.

[stippi]

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

[diver]

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

[diver]

Still here in hrev23879

[emitrax]

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?

[diver]

I managed to deadlock it in the same way in hrev25588.

[scottmc]

Can anyone other than diver reproduce this? I wasn't able to... If this stays open I think it should be moved from R1/alpha to R1, that is unless someone else is able to reproduce it.

[axeld]

I completely agree. While deadlocking the app_server is truly unfortunate, if one has to try that hard to do it (I didn't manage to do so), it shouldn't stop the alpha.

[stippi]

Most likely fixed by hrev28217. We fixed exactly such a problem. The deadlock happened when popping up a new window, which also activates it and thus triggers a workspace change when you managed to switch the workspace before the window finally showed. Please reopen if you can still reproduce (we only managed to still reproduce it with StressTest).