SEModCommunity / SE-Community-Mod-API

Space Engineers Community Modding API
GNU Lesser General Public License v3.0
60 stars 47 forks source link

BUG: GUI Freezes, deadlock refreshing internal data #105

Closed Tyrsis closed 10 years ago

Tyrsis commented 10 years ago

This has been happening on my live server intermittently, but I've finally caught it during a local debug. It appears the GUI is deadlocking with the server when it's refreshing it's treeview. It's random of course, but it's a race condition anyway. I know you're moving towards WCF, but until that's 100% this could be a bit of an issue for people still running the GUI.

Here's the two threads that are deadlocked. The GUI is frozen obviously and unresponsive. The server also is unresponsive, though my plugin threads are still going. Sorry about the formatting here, couldn't really paste it in and have it look good.

http://pastebin.com/VbjWrbYf

chessmaster42 commented 10 years ago

This isn't the first time I've heard this problem but I haven't been able to reproduce the problem on my end. Also, that bit of VS output you linked to doesn't help much. Can you provide more detail?

As soon as I can find the source I'll be fixing this asap.

Tyrsis commented 10 years ago

Oh I figured that thread dump would be enough. Not sure what other info I can provide at this point. It's not like I'm doing anything special. In fact I'm usually not doing anything at all, and it's idling and that occurs.

Tyrsis commented 10 years ago

I have had this happen again in debug. If you look at the thread dump you can see the race, but I'll show it here:

In: RefreshInternalData() called by Refreshing the treeview (TreeViewRefresh()) on the main thread:

m_rawDataHashSetResourceLock.AcquireExclusive(); m_rawDataListResourceLock.AcquireExclusive(); LOCK --> m_rawDataObjectBuilderListResourceLock.AcquireExclusive();

Waiting for m_rawDataObjectBuilderListResourceLock

In: SectorEntity.InternalRefreshObjectBuilderMap() in a worker thread:

m_rawDataObjectBuilderListResourceLock.AcquireExclusive(); LOCK --> m_rawDataHashSetResourceLock.AcquireExclusive();

You can pretty clearly see the deadlock here. I think if you just reorder the locks to match, it should be fine, as they won't race anymore, and only one lock will occur.

chessmaster42 commented 10 years ago

Okay, this should now be fixed in the latest dev build. Here's hoping that it actually worked.

chessmaster42 commented 10 years ago

Fixes have not worked. Still broken for some reason. Anyone who has had this problem, please re-test on the latest build and post back your findings.

Hasbinbad commented 10 years ago

1.) load sese 2.) close stock GUI 3.) run/connect remote gui 4.) type /gui in the chat of the remote GUI 5.) close the remote GUI 6.) click entities tab 7.) click an entity 8.) click impoort expected: import dialogue actual: stock GUI Not Responding (however, server is still running fine at this point, without the "no connection message," and one is able to transfer items in game). 9.) click the x in the stock GUI to close it expected: stock GUI shuts down. actual: closes the console too (shuts down server)

I haven't repeated this, but that is step by step why some issue happened and my observations about it.

chessmaster42 commented 10 years ago

Okay, more attempts at fixing this in ac75214e0eeec4780183686c28a9e099d6469948 and in the dev build 0.2.9.9. Please download and re-test.

Tyrsis commented 10 years ago

Btw - my locking issue has been gone since you implemented the fix. So the one I posted about is definitely gone.