AWS Thinkbox Discussion Forums

c++ runtime error when executing script

Deprecated Deadline 7 Bug Reports
#1

We are getting a c++ runtime error when trying to execute a simple script using ctypes:

create the following script c:\temp\test.py:

print ('hello world!')
import ctypes
import ctypes.util
sMSV=ctypes.util.find_msvcrt()
print ("libc=%s"%sMSV)
libc = ctypes.CDLL(sMSV)
print('loaded')

Then execute it via:
C:\Program Files\Thinkbox\Deadline7\bin>deadlinecommand ExecuteScript “c:\temp\test.py”

We get the following crash:

Microsoft Visual C++ Runtime Library

Runtime Error!

Program: C:\Program Files\Thinkbox\Deadline7\bin\deadlinecommand.exe

R6034

An application has made an attempt to load the C runtime library incorrectly.
Please contact the application’s support team for more information.

OK

#2

The odd thing is, that running it via dpython does not crash.

#3

You can also crash it with a script like this:

import _ctypes
a=_ctypes.LoadLibrary(‘msvcr90.dll’,_ctypes.RTLD_LOCAL)

Some dll conflict, but i can’t seem to be able to figure it out… :-\

#4

Something is really weird…

This is the current script im trying:

import platform
import ctypes

print ("Compiler: %s" % (platform.python_compiler()))
def tryToLoad(sName):
    _handle = ctypes.windll.kernel32.GetModuleHandleA(sName)
    print ('%s handle: %s' % (sName, _handle))

tryToLoad('msvcr90.dll')
tryToLoad('msvcr100.dll')
tryToLoad('msvcr110.dll')

The result:

Compiler: MSC v.1500 64 bit (AMD64)
msvcr90.dll handle: 0
msvcr100.dll handle: 1889271808
msvcr110.dll handle: 0

Why is the 9.0 runtime not loaded (instead of the 10.0 runtime), when the python compiler is v.1500? Seems like the cpython embedded in deadline is loading the wrong runtime?

cheers
l

#5

Hey Laszlo,

That’s strange… might have to do some testing on our side to figure out what’s going on.

It definitely makes sense that it’s loading msvcr100 when embedding, since Deadline is built with VS2010 and would be loading those runtimes. Using your test code in dpython, I get that msvcr90 is loaded, which might explain the difference. I wonder if this is just a conflict between the runtimes that Deadline is built against vs the ones that our Python is, and I guess it just doesn’t surface for most things… Might have to take a look at rebuilding our cPython =/

#6

Yeah most likely a conflict there… The thing is, deadline currently ships with the “official” python compiler for its internal cpython (v9 / msc1500). So its compatible with most downloaded pre-built binaries.

Maya / nuke etc are a bit special, they come with their own flavours of python. So in-house, we maintain about 6+ different binary sets based on qt & python compilers (tons of fun).
Should deadline change its internal version of the compiler, i hope it would fall into one of the existing combinations…, but it will most definitely have a side-effect on a lot of people using off the shelf binaries: they would have to start building their own versions of those libs.

#7

I haven’t mentioned it, but this came up due to the imagemagick libraries crashing on import.

#8

Yeah… good point on the Python compatibility side. I don’t know that we’d want to move off of the standard MSVC if it will break literally everything else.

Have you guys been able to work around this conflict? I know I was looking at something similar with another client trying to load Draft inside of Nuke’s embedded Python, and I just couldn’t figure it out, for similar reasons (though OpenColorIO was the culprit that time).

#9

Our current workaround is not ideal, we spawn a python process (from the python post task) that runs in standalone python. But we lose all logging etc.

This should be fixed in the binaries somehow, as other dll conflicts could also pop up randomly based when variables pass compiler boundaries.

#10

Yeah, we’ll look into it. I’m sure it’s something we’re doing wrong on the Deadline-side that’s preventing Windows SxS from loading both version of the CRT properly…

Privacy | Site terms | Cookie preferences