Opened 13 years ago

Closed 11 years ago

#757 closed bug (fixed)

[app_server] deadlock on workspace switching

Reported by: diver Owned by: axeld
Priority: critical Milestone: R1
Component: Servers/app_server Version:
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by axeld)

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.

Attachments (1)

app_server_crash_9.PNG (23.9 KB) - added by diver 13 years ago.
back trace for comment #1

Download all attachments as: .zip

Change History (29)

comment:1 Changed 13 years ago by diver

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

comment:2 Changed 13 years ago by 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...

comment:3 Changed 13 years ago by 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 ;-)

Changed 13 years ago by diver

Attachment: app_server_crash_9.PNG added

back trace for comment #1

comment:4 Changed 13 years ago by axeld

Component: GeneralUser Interface/Application Server
Description: modified (diff)
Platform: All

comment:5 Changed 13 years ago by axeld

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

comment:6 in reply to:  5 Changed 13 years ago by 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...

comment:7 Changed 13 years ago by 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)

comment:8 Changed 13 years ago by diver

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

comment:9 Changed 13 years ago by 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!

comment:10 Changed 12 years ago by diver

This deadlock still with us at hrev21691.

comment:11 Changed 12 years ago by axeld

Milestone: R1R1/alpha

comment:12 Changed 12 years ago by stippi

Resolution: fixed
Status: newclosed

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.

comment:13 Changed 12 years ago by diver

Resolution: fixed
Status: closedreopened

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

comment:14 Changed 12 years ago by 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.

comment:15 Changed 12 years ago by 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.

comment:16 in reply to:  15 Changed 12 years ago by 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).

comment:17 Changed 12 years ago by 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.

comment:18 Changed 12 years ago by stippi

Resolution: fixed
Status: reopenedclosed

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

comment:19 Changed 12 years ago by diver

Resolution: fixed
Status: closedreopened

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.

comment:20 Changed 12 years ago by stippi

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

comment:21 Changed 12 years ago by diver

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

comment:22 Changed 11 years ago by diver

Still here in hrev23879

comment:23 Changed 11 years ago by 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?

comment:24 Changed 11 years ago by diver

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

comment:25 Changed 11 years ago by 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.

comment:26 Changed 11 years ago by axeld

Milestone: R1/alpha1R1

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.

comment:27 Changed 11 years ago by axeld

Priority: blockercritical

comment:28 Changed 11 years ago by stippi

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.