Job script exception buried by another Monitor exception?

nrusch · April 30, 2016, 1:26am

I have a job script that has worked fine in the past (i.e. when we were using Deadline 7.1), but as of 7.2.1.10, now throws an incredibly unhelpful exception that I think may be masking an internal exception in the script itself.

Traceback (most recent call last): File "DeadlineUI\UI\Commands\ScriptCommands.py", line 103, in InnerExecute PythonNetException: name Parameter name: Name cannot be empty at System.Reflection.MonoAssembly.GetType (System.String name, Boolean throwOnError, Boolean ignoreCase) [0x00000] in <filename unknown>:0 at System.Reflection.Assembly.GetType (System.String name) [0x00000] in <filename unknown>:0 at Python.Runtime.AssemblyManager.LookupType (System.String qname) [0x00000] in <filename unknown>:0 at Python.Runtime.ModuleObject.GetAttribute (System.String name, Boolean guess) [0x00000] in <filename unknown>:0 at Python.Runtime.ImportHook.__import__ (IntPtr self, IntPtr args, IntPtr kw) [0x00000] in <filename unknown>:0 at (wrapper native-to-managed) Python.Runtime.ImportHook:__import__ (intptr,intptr,intptr) at (wrapper managed-to-native) Python.Runtime.Runtime:PyObject_Call (intptr,intptr,intptr) at Python.Runtime.ImportHook.__import__ (IntPtr self, IntPtr args, IntPtr kw) [0x00000] in <filename unknown>:0 at (wrapper native-to-managed) Python.Runtime.ImportHook:__import__ (intptr,intptr,intptr) at (wrapper managed-to-native) Python.Runtime.Runtime:PyObject_Call (intptr,intptr,intptr) at Python.Runtime.ImportHook.__import__ (IntPtr self, IntPtr args, IntPtr kw) [0x00000] in <filename unknown>:0 at (wrapper native-to-managed) Python.Runtime.ImportHook:__import__ (intptr,intptr,intptr) at (wrapper managed-to-native) Python.Runtime.Runtime:PyObject_Call (intptr,intptr,intptr) at Python.Runtime.ImportHook.__import__ (IntPtr self, IntPtr args, IntPtr kw) [0x00000] in <filename unknown>:0 at (wrapper native-to-managed) Python.Runtime.ImportHook:__import__ (intptr,intptr,intptr) at (wrapper managed-to-native) Python.Runtime.Runtime:PyObject_Call (intptr,intptr,intptr) at Python.Runtime.ImportHook.__import__ (IntPtr self, IntPtr args, IntPtr kw) [0x00000] in <filename unknown>:0 at (wrapper native-to-managed) Python.Runtime.ImportHook:__import__ (intptr,intptr,intptr) at (wrapper managed-to-native) Python.Runtime.Runtime:PyObject_Call (intptr,intptr,intptr) at Python.Runtime.ImportHook.__import__ (IntPtr self, IntPtr args, IntPtr kw) [0x00000] in <filename unknown>:0 at (wrapper native-to-managed) Python.Runtime.ImportHook:__import__ (intptr,intptr,intptr) at (wrapper managed-to-native) Python.Runtime.Runtime:PyObject_Call (intptr,intptr,intptr) at Python.Runtime.PyObject.Invoke (Python.Runtime.PyObject[] args) [0x00000] in <filename unknown>:0 at Python.Runtime.PyObject.InvokeMethod (System.String name, Python.Runtime.PyObject[] args) [0x00000] in <filename unknown>:0 at FranticX.Scripting.PythonNetScriptEngine.CallFunction (System.String functionName, Python.Runtime.PyObject[] args) [0x00000] in <filename unknown>:0

Can anyone tell me what this might be masking?

JustinB · May 2, 2016, 9:56pm

Could you post your script? It looks like its failing to find the module name but I’m not sure why.

nrusch · May 3, 2016, 1:46am

I don’t think the script is going to tell you much, since it’s just a stub file that loads the real script from a location that varies based on the current environment (to work around the lack of support for customization when it comes to sourcing external code). The real script that it loads won’t mean much to you either, since it’s basically just wrapping error-handling around a bunch of calls into custom external modules.

I tried copying the real script into the repository directory and running it directly (after a restart), but the Monitor doesn’t seem to respect the environment of the shell it was launched from when it comes to finding Python modules (which boggles my mind), so none of the custom modules can be imported.

nrusch · May 3, 2016, 2:04am

Just to follow up, after getting the real script to run by manually extending sys.path, it throws the same (original) error.

jgaudet · May 5, 2016, 12:35am

Hey Nathan,

Looks like that error is happening in Python for .NET’s import hook, which is trying to find a .NET class / namespace that matches a Python import statement at the time this exception is getting thrown.

Note that it only looks in the .NET namespace after it tries to import it through Python regularly and fails to load it (specifically due to an ImportError occurring) – so it might be that prior to the upgrade, it was finding the Python module in question (or something that it imports) properly, and after it was not.

My guess, looking at the import hook code, and taking into account the fact that the error is complaining about an empty type name, is that it might be a relative import somewhere that’s not being found that is causing the issue (e.g. “from . import blah”). Judging by the length of the recurring “import” chain in the stacktrace, it might be relatively deep in the chain of imported modules.

I’m not sure why this has suddenly become a problem with the upgrade – I don’t think we’ve changed that import hook code recently. We can definitely add a fix to this though, which should result in the ‘proper’ error coming through.