Python DLL load failed error

Problem

You execute a Python program that uses a module and the module throws up this error at runtime:

ImportError: DLL load failed: %1 is not a valid Win32 application.

Solution

This is usually caused by a mismatch in the DLL of the module. I faced this error when I had mistakenly installed a 32-bit Python module (numpy in this case) on to a 64-bit Python installation. The error is thrown when the communication between the 64-bit Python and the 32-bit module DLL does not work, as expected. The error went away after I installed a 64-bit version of the module.

Tried with: Python 3.2 64-bit on Windows 7

Python version not found in registry error

Problem

Once you start installing many Python modules, you are sure to run into this error. When installing a Python module, it pops up this error:

Python version 3.2 required, which was not found in the registry.

I do have Python 3.2 installed, so what’s up?

Solution

The problem is that some module installers look in the wrong place for Python version information. For example, in the case of this one module, the installer was looking for HKEY_CURRENT_USER\SOFTWARE\Python\PythonCore\3.2 in the registry. I found that my Python 3.2 installer had placed this information in HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.2 instead.

Once you know the reason, solving it is easy. Open Registry Editor (may need administrator privilege) and export HKEY_LOCAL_MACHINE\SOFTWARE\Python\PythonCore\3.2 into a text file. Open the exported .reg file in a text editor and replace the HKEY_LOCAL_MACHINE entries to HKEY_CURRENT_USER. Add these new entries back to the registry (here is how). The module installer should now be able to proceed without throwing the error.

Tried with: Python 3.2 64-bit on Windows 7

PyOpenGL GLUT ctypes error

Installing PyOpenGL can be quite painful on 64-bit Python 3.x with Windows 7. But, once you that is done, you might face this error in your program:

glutCreateWindow( "cube" )
# ctypes.ArgumentError: argument 1: <class 'TypeError'>: wrong type

ctypes provides the data types to communicate with C libraries. I got the above error when I was passing a string to a GLUT function. The error is caused because underneath the PyOpenGL call is an old-school C function expecting ASCII text, whereas Python 3.x gives it Unicode text by default.

So, the solution is to pass the string in the bytes format. In the above case, the error was solved by changing it to:

glutCreateWindow( b"cube" )

Tried with: PyOpenGL-3.0.2a6.win-amd64-py3.2

Udacity course not loading with Firefox

Problem

Udacity courses are stuck at the Loading stage when you try to view them with Firefox.

Solution

This problem is caused by the HTTPS Everywhere addon for Firefox. Udacity uses YouTube for their videos. And by looking at the messages in the Error Console of Firefox, you can see that there is some problem. It looks like HTTP Youtube is trying to load content from HTTPS Youtube. HTTPS Everywhere does not like this behaviour and thus blocks it.

To be able to load Udacity courses with Firefox, disable the rulesets for all the Youtube entries in the Options of HTTPS Everywhere. On my system, there were two entries: YouTube (partial) and YouTube-nocookie, and I disabled both of them. Once these changes are applied, Udacity courses should load. Restarting Firefox is not needed.

Tried with: Firefox 10.0 and HTTPS Everywhere 2.0.1

How to do error checking in CUDA

Error checks in CUDA code can help catch CUDA errors at their source. There are 2 sources of errors in CUDA source code:

  1. Errors from CUDA API calls. For example, a call to cudaMalloc() might fail.
  2. Errors from CUDA kernel calls. For example, there might be invalid memory access inside a kernel.

All CUDA API calls return a cudaError value, so these calls are easy to check:

if ( cudaSuccess != cudaMalloc( &fooPtr, fooSize ) )
    printf( "Error!\n" );

CUDA kernel invocations do not return any value. Error from a CUDA kernel call can be checked after its execution by calling cudaGetLastError():

fooKernel<<< x, y >>>(); // Kernel call
if ( cudaSuccess != cudaGetLastError() )
    printf( "Error!\n" );

These two types of checks can be elegantly wrapped up in two simple error-checking functions like this:

Using these error checking functions is easy:

CudaSafeCall( cudaMalloc( &fooPtr, fooSize ) );

fooKernel<<< x, y >>>(); // Kernel call
CudaCheckError();

These functions are actually derived from similar functions which used to be available in the cutil.h in old CUDA SDKs.

Notice that the calls are inline functions, so absolutely no code is produced when CUDA_CHECK_ERROR is not defined. These utility functions can prove their worth to catch errors as close as possible to the error source only if they are used everywhere. So, use them to wrap all CUDA API calls and after all your kernel calls 🙂

Tried with: CUDA 5.5