[SciPy-Dev] Debugging a segfault

[Andrew Nelson]

Is there any significance to exiting with Error Code 2? Is that:

#define ENOENT           2      /* No such file or directory */


On 13 September 2017 at 12:04, Andrew Nelson <andyfaff at gmail.com> wrote:

> Installing pytest-faulthandler did not give a traceback. I'm using Python
> 3.6, not sure if that's the issue. However, using verbose mode indicated
> that it's test_fortran_roundtrip that causes the issue, as Pauli thought.
>
> commodore$ python runtests.py -v -s io
> Building, see build.log...
> Build OK (0:00:07.503852 elapsed)
> ===============================================================================
> test session starts ==============================
> =================================================
> platform linux -- Python 3.6.2, pytest-3.2.2, py-1.4.34, pluggy-0.4.0 --
> /home/anz/bin/python
> cachedir: ../../../../../.cache
> rootdir: /home/anz/software/scipy-master, inifile: pytest.ini
> plugins: faulthandler-1.3.1
> collected 268 items
> <snip>
> scipy/io/tests/test_fortran.py::test_fortranfile_write_mixed_record PASSED
> scipy/io/tests/test_fortran.py::test_fortran_roundtrip commodore$
>
>
> I'm definitely using gfortran:
>
> commodore$ ldd _test_fortran.cpython-36m-x86_64-linux-gnu.so
> linux-vdso.so.1 =>  (0x00007fffc75d1000)
> libgfortran.so.1 => /usr/lib64/libgfortran.so.1 (0x00002b0495f3b000)
> libm.so.6 => /lib64/libm.so.6 (0x00002b04961d3000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00002b0496456000)
> libc.so.6 => /lib64/libc.so.6 (0x00002b0496664000)
> /lib64/ld-linux-x86-64.so.2 (0x000000398a400000)
>
> The gfortran specs are:
>
> commodore$ gfortran -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info --enable-shared --enable-threads=posix
> --enable-checking=release --with-system-zlib --enable-__cxa_atexit
> --disable-libunwind-exceptions --enable-libgcj-multifile
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> --enable-java-awt=gtk --disable-dssi --disable-plugin
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
> --with-cpu=generic --host=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)
>
>
> I also tried running the tests in gdb, using the instructions that were
> provided, but that didn't give me a stack trace either.
>
> A.
>
> On 13 September 2017 at 00:18, Andrew Nelson <andyfaff at gmail.com> wrote:
>
>> On 12 Sep 2017 11:57 pm, "Pauli Virtanen" <pav at iki.fi>
>>
>> Possibly, the fortran compiler on the cluster is some more exotic than
>> gfortran, its unformatted i/o is not compatible, and it handles errors by
>> crashing rather than doing something else.
>>
>>
>> I'm using gfortran, I'm not sure what version.
>>
>>
>
>
> --
> _____________________________________
> Dr. Andrew Nelson
>
>
> _____________________________________
>



-- 
_____________________________________
Dr. Andrew Nelson


_____________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20170913/9173a9cb/attachment.html>