New issue 11 by Heiner.B...@psi.ch: Segmentation fault at "from libtiff
import TIFF" / dlopen(...tif_lzw.so") with python 2.6
http://code.google.com/p/pylibtiff/issues/detail?id=11
What steps will reproduce the problem?
1. run enthought python distribution 6.3-2 on scientific linux 5
2. build/install pylibtiff (revision 70)
3. run python -c "from libtiff import TIFF"
What is the expected output? What do you see instead?
$ python -v -d -c "from libtiff import TIFF"
....
import copy # precompiled from
/scratch/epd-6.3-2-rh5-x86/lib/python2.6/copy.pyc
# /scratch/pylibtiff.i386/lib/python/libtiff/tiff_base.pyc matches
/scratch/pylibtiff.i386/lib/python/libtiff/tiff_base.py
import libtiff.tiff_base # precompiled from
/scratch/pylibtiff.i386/lib/python/libtiff/tiff_base.pyc
# /scratch/pylibtiff.i386/lib/python/libtiff/lsm.pyc matches
/scratch/pylibtiff.i386/lib/python/libtiff/lsm.py
import libtiff.lsm # precompiled from
/scratch/pylibtiff.i386/lib/python/libtiff/lsm.pyc
dlopen("/scratch/pylibtiff.i386/lib/python/libtiff/tif_lzw.so", 102);
Segmentation fault
What version of the product are you using? On what operating system?
$ python -V
Python 2.6.6 -- EPD 6.3-2 (32-bit)
$ uname -a
Linux pc6490 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:56:26 EST 2010 i686
i686 i386 GNU/Linux
Please provide any additional information below.
Works o.k. with python 2.7.
Importing tif_lzw works fine with Python 2.6.5 on Ubuntu Linux.
Could you try importing libtiff to python via gdb or ddd to get more
information about the segmentation fault. Also check that the libtiff
build/install
is clean (no build/ directory when running the build command).
Same issue here. It could be a bug in EPD.
$ python -V
Python 2.6.6 -- EPD 6.3-2 (64-bit)
$ uname -a
Linux 2.6.37-12-generic #26-Ubuntu SMP Wed Jan 5 18:38:48 UTC 2011 x86_64
GNU/Linux
Stack trace attached.
Problem occurs on call to import_array(). Copying the tif_lzw.so into the
current directory and importing directly works fine.
Attachments:
libtiff_bug.txt 11.5 KB
How was libtiff built? If with Python 2.7 then try rebuilding it
with Python 2.6 and against numpy that EPD provides.
The only version on python I have installed is 2.6.6. I do have a system
python 2.6.6, but numpy is not installed there. I have rebuilt from a
fresh directory. Also:
$ ldd
/opt/epd/epd-6.3-2-rh5-x86_64/lib/python2.6/site-packages/libtiff/tif_lzw.so
linux-vdso.so.1 => (0x00007fff3f192000)
libpython2.6.so.1.0 =>
/opt/epd/epd-6.3-2-rh5-x86_64/lib/libpython2.6.so.1.0 (0x00007f3de03e4000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007f3de01a1000)
libc.so.6 => /lib/libc.so.6 (0x00007f3ddfe1d000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f3ddfc19000)
libutil.so.1 => /lib/libutil.so.1 (0x00007f3ddfa16000)
libm.so.6 => /lib/libm.so.6 (0x00007f3ddf792000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3de0980000)
I wonder if you can build and import any numpy based extension module in
your system.
For example, try
echo -e "subroutine foo\nend" > foo.f90
f2py -c -m bar foo.f90
python -c 'import bar; print bar.__doc__'
Does it work?
Yes, I have never had problems with numpy extensions using EPD in the past.
Attachments:
test_module.txt 4.2 KB
Hmm, then I have no idea what could be wrong.
Try importing numpy before importing libtiff.
You can also edit libtiff/src/tif_lzw.c by removing its
code until it will import successfully; this might give some ideas
what is going on.
Here's an idea. In the header of tif_lzw.c try to change the following line
#define PY_ARRAY_UNIQUE_SYMBOL PyArray_API
to
#define PY_ARRAY_UNIQUE_SYMBOL PyArray_API_tif_lzw
and rebuild libtiff.