PIL error when running tilestache-server.py

[johtso]

When trying to run tilestache-server.py I get the following error: AccessInit: hash collision: 3 for both 1 and 1.

From what I've read, this seems to be an issue where PIL ends up being imported more than once in a script and conflict.

I'm not sure what exactly is the cause of the issue, but adding this to tilestache-server.py got it running:

import sys
import PIL.Image
sys.modules['Image'] = PIL.Image

[pwicks]

Getting to the likely root cause: Importing Image twice, possibly due to some difference in the paths that refer to it in subsequent import attempts (symbolic link?). Do you have more than one Python version installed? Is your '''PYTHONPATH''' in '''.bash_profile''' pointing to a single library? Are there multiple python libraries in the '''$PATH'''? Does the shared object exist in more than one path on the filesystem? I guess the import code should be as carefully written as your patch to '''tilestache-server.py'''. Considering that your patch is a useful improvement, correcting the root cause might not be necessary. I'll keep poking at this until I either get to the bottom of it or run out of time (probably the latter but hopefully the former).

[NelsonMinar]

I just ran into this bug on my Mac using a Homebrew version of Python. It seems to be a well-known problem with two different ways to import PIL Image. Adding johtso's sys.modules patch to the top of my CGI and Gunicorn python config fixed the problem for me.

This problem occurs in other libraries: Django for instance. I believe the solution is to ensure that TileStache and all its related code only ever imports either Image or PIL.Image. Unfortunately it's not clear which one is correct. Here's a couple of Python sessions demonstrating the problem.

Python 2.7.4 (default, Apr 15 2013, 07:26:56)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import Image
>>> sys.modules["Image"]
<module 'Image' from '/usr/homebrew/Cellar/python/2.7.4/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PIL/Image.pyc'>
>>> import PIL.Image
AccessInit: hash collision: 3 for both 1 and 1

Python 2.7.4 (default, Apr 15 2013, 07:26:56)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.27)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import PIL.Image
>>> sys.modules["PIL.Image"]
<module 'PIL.Image' from '/usr/homebrew/lib/python2.7/site-packages/PIL/Image.pyc'>
>>> import Image
AccessInit: hash collision: 3 for both 1 and 1

[erictheise]

I'm hitting this same issue using a brew installed version of Python 2.7.5, but the fix proposed here results in

$ ./scripts/tilestache-server.py 
Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6
$ 

The related fix proposed in #134 has no effect, I still get

AccessInit: hash collision: 3 for both 1 and 1

[rburhum]

@erictheise your problem is most likely related to the mapnik import. This happens when you have installed mapnik through homebrew, but are actually using the system python to import it. This was a very common error for our devs.

Check that the system python is not being used by doing something like (fyi, my virtualenv called indoor is activated):

(indoor)rburhum@peru.local ~ $ python -c 'import sys;import pprint; pprint.pprint(sys.path)'
['',
 '/usr/local/lib/python2.7/site-packages/distribute-0.6.40-py2.7.egg',
 '/usr/local/lib/python2.7/site-packages/pip-1.3.1-py2.7.egg',
 '/usr/local/lib/python2.7/site-packages',
 '/Users/rburhum',
 '/Users/rburhum/.virtualenvs/indoor/lib/python27.zip',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/plat-darwin',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/plat-mac',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/plat-mac/lib-scriptpackages',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/lib-tk',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/lib-old',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/lib-dynload',
 '/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7',
 '/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin',
 '/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk',
 '/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac',
 '/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages',
 '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/site-packages',
 '/usr/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info',
 '/usr/local/lib/python2.7/site-packages/wx-2.9.4-osx_cocoa']
(indoor)rburhum@peru.local ~ $

There should be no system python. If there is, you want to destroy that virtualenv and recreate it.

This is what I have in my ~/.bashrc to make sure the right virtualenv settings from homebrew is being used:

# Setting up the VirtualEnv
export WORKON_HOME=$HOME/.virtualenvs
export VIRTUALENVWRAPPER_PYTHON=/usr/local/bin/python2.7
#export VIRTUALENVWRAPPER_VIRTUALENV_ARGS='--no-site-packages'
export PIP_VIRTUALENV_BASE=$WORKON_HOME
export PIP_RESPECT_VIRTUALENV=true

if [[ -r /usr/local/bin/virtualenvwrapper.sh ]]; then
    source /usr/local/bin/virtualenvwrapper.sh
else
    echo "WARNING: Can't find virtualenvwrapper.sh"
fi

export PYTHONPATH="/usr/local/lib/python2.7/site-packages:$PYTHONPATH"

[rburhum]

@NelsonMinar I cannot reproduce the errors using both of your examples

(indoor)rburhum@peru.local ~ $ python
Python 2.7.5 (default, May 28 2013, 14:33:04)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import Image
>>> sys.modules["Image"]
<module 'Image' from '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/site-packages/PIL/Image.pyc'>
>>> import PIL.Image
>>>

Second Example:

(indoor)rburhum@peru.local ~ $ python
Python 2.7.5 (default, May 28 2013, 14:33:04)
[GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> import PIL.Image
>>> sys.modules["PIL.Image"]
<module 'PIL.Image' from '/Users/rburhum/.virtualenvs/indoor/lib/python2.7/site-packages/PIL/Image.pyc'>
>>> import Image
>>>

[erictheise]

Belated thanks, @rburhum & @NelsonMinar. I was doing this on a machine that predates homebrew, plus the good doctor is not always correct in his prognoses. But Ragi's intuition was correct and it turns out that a boost library was linked against the system python as opposed to my brewed python.

[pavgup]

For the googlers, you can verify whether or not boost-python is causing problems by running:

brew list --verbose boost-python | grep dylib | xargs otool -L

If you end up seeing mentions of /System in the output that follows, you should do the following:

brew uninstall boost-python
brew install --build-from-source boost-python

Good luck!