I ran into an issue about Maya 2016 extension 2 hanging earlier this week. The customer has a custom locator node in their scene and Maya hangs when running code like below:
import maya.cmds as cmds
cmds.evaluationManager(mode="parallel")
for i in range(10):
cmds.currentTime(i)
After spending some time for debugging, the issue was found. It turns out that when Maya is executing Python, it will acquire a Python lock for the interpreter. During the parallel evaluation of your scene caused by cmds.currentTime, another working thread is created and tries to acquire the same lock, resulting in a deadlock scenerio. In Maya 2017, it only happens when MAYA_RETAIN_PYTHON_GIL is set in your system environment. MAYA_RETAIN_PYTHON_GIL is for the users who are experiencing performance issues when executing high volumes of python commands. Maya will be more prone to deadlocks if custom Python nodes are evaluating in other threads.
To avoid the deadlock, please use Mel command only if you are going to evaluate the scene. You could also try to rewrite your nodes in C++ to avoid sharing a lock with the Python interpreter.
does this also apply to high volume mel commands? I am having the same issue when i evaluate a mel command at every frame on the time line, the system locks and crashes due to a memory access violation. i assume because the previous command was not finished operating on the object before the new mel command was called on the same object.
Posted by: Robert Cervellione | August 06, 2016 at 05:40 AM
I think this is applied to commands need to be executed during idle. Maybe it is a little different from your issue.
Posted by: Chengxi Li | August 11, 2016 at 12:35 AM
We are also working with custom locators and something baffles me...
if you do a spaceLocator or nurbsCurve, copy it 400 times and set keys on the transform you might get about 200 fps when doing playback...
Compile the footPrintNode from the devkit and do the same and you get 23 fps (60 fps with the geometryOverride version)
Without keys on the transform the viewport performance is fine.... any clue why?
Best wishes... Jakob
Posted by: Jakob Steffensen | August 17, 2016 at 07:54 AM
This bug is pretty nasty. Even calling out to mel from python causes the crash so unless you can rewrite your whole tool in mel the work around isn't doable. Further, even disabling parallel evaluation will not fix it in all cases. If parallel is disabled but viewport2.0 is enabled it will usually still crash when calling cmds.playblast(). In other words you can't use python node plugins with viewport2.0 OR parallel eval. Not good.
Posted by: Luke Harris | August 18, 2016 at 02:05 AM