Segfault with libz

[ronpandolfi]

Using azimuthal integration on Ubuntu 16.04.3 LTS results in a seg fault with the the below backtrace, identifying an incompatibility. I tried building newer versions of libz (zlib) from source, but had the same issue.

GDB stack trace:

#0 0x00007ffff71d1908 in crc32 () from /lib/x86_64-linux-gnu/libz.so.1
#1 0x00007fffcd3a387a in __pyx_pf_5pyFAI_3ext_7fastcrc_crc32 (__pyx_v_data=, __pyx_self=) at pyFAI/ext/fastcrc.c:1504
#2 __pyx_pw_5pyFAI_3ext_7fastcrc_1crc32 (__pyx_self=, __pyx_v_data=0x7fff8c0feb70) at pyFAI/ext/fastcrc.c:1467
...

[vallsv]

Hi. It is the second time we have this feed back.

fastcrc is our own c code, and it do not need any dependency. Then it is not supposed to have access to external lib. Then we don't really understand what's happen here.

To solve the problem, you can delete out fastcrc.so library. It is provided just in case, else it will use a CRC algorithm provided by another Python library like libz. It is not a real fix, but let us know if is solve your problem for now.

[vallsv]

Here is the previous computer used for the same problem:

• Windows 7, proc is Intel® Core™ i5-4590, the virtualized Linux is VirtualBox 3.13.0-100-generic lintian warning spell and missing manpage #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[kif]

On Wed, 09 Aug 2017 22:18:35 -0700 Ronald Pandolfi ***@***.***> wrote: Using azimuthal integration on Ubuntu 16.04.3 LTS results in a seg fault with the the below backtrace, identifying an incompatibility. I tried building newer versions of libz (zlib) from source, but had the same issue. GDB stack trace: #0 0x00007ffff71d1908 in crc32 () from /lib/x86_64-linux-gnu/libz.so.1 #1 0x00007fffcd3a387a in __pyx_pf_5pyFAI_3ext_7fastcrc_crc32 (__pyx_v_data=<optimized out>, __pyx_self=<optimized out>) at pyFAI/ext/fastcrc.c:1504 #2 __pyx_pw_5pyFAI_3ext_7fastcrc_1crc32 (__pyx_self=<optimized out>, __pyx_v_data=0x7fff8c0feb70) at pyFAI/ext/fastcrc.c:1467 ...

I managed to reproduce the bug: with "sudo apt-get install pyFAI", it works. But a "pip install pyFAI" which uses the manylinux binary wheel it does not. When locally re-compiled it should work (compilation ongoing) Jérôme Kieffer

[kif]

It is really surprising as fastcrc only links libpthread and libc (and not libz!) as Valentin already commented.

[kif]

I confirm that after recompilation it works. I had a look at the assembly and it may be a bug in the cython generated code (or a bug related to gcc 4.2 used for the manylinux build)

[kif]

the bug also exists on debian9 with python2.7 but not 3.5