Executing the following python code in a python shell "from rpy2 import robjects" causes the following Exception: Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.5/site-packages/rpy2/robjects/__init__.py", line 16, in <module> import rpy2.rinterface as rinterface File "/usr/lib64/python3.5/site-packages/rpy2/rinterface/__init__.py", line 92, in <module> from rpy2.rinterface._rinterface import (baseenv, ImportError: libRblas.so: cannot open shared object file: No such file or directory Executing a python script containing the line above causes a segfault, which ABRT doesn't successfully manage to report: Segmentation fault (core dumped) Looking at the folder /usr/lib64/R/lib, libRblas.so is definitely there, but is a symlink to /usr/lib64/libopenblas.so.0, maybe that confuses the rpy2 module initialisation. Version-Release number of selected component (if applicable): python3-rpy-2.8.3-1.fc25.x86_64 R-core-3.3.2-2.fc25.x86_64
I can not reproduce it. I am running F25 as well on x86_64 and it works (using ipython2 and 3): In [1]: import rpy2 In [2]: from rpy2 import robjects In [3]: Could this be related with bug #1391491 ? Could you, please, update to the latest version of openblas in updates-testing? openblas-0.2.19-2.fc25.x86_64
Still happens with the newest openblas version: openblas-0.2.19-3.fc25.x86_64 $ python3 Python 3.5.2 (default, Sep 14 2016, 11:28:32) [GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import rpy2 >>> from rpy2 import robjects Segmentation fault (core dumped) I also ran "rpm -Va" to check if my installation got corrupted somehow, but no files related to R / python3 / openblas show up with errors.
With valgrind, I got the following errors: [deca@asudora ~]$ valgrind python3 ==6869== Memcheck, a memory error detector ==6869== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al. ==6869== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info ==6869== Command: python3 ==6869== Python 3.5.2 (default, Sep 14 2016, 11:28:32) [GCC 6.2.1 20160901 (Red Hat 6.2.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import rpy2 >>> from rpy2 import robjects ==6874== Warning: invalid file descriptor 1024 in syscall close() ==6874== Warning: invalid file descriptor 1025 in syscall close() ==6874== Warning: invalid file descriptor 1026 in syscall close() ==6874== Warning: invalid file descriptor 1027 in syscall close() ==6874== Use --log-fd=<number> to select an alternative log fd. ==6874== Warning: invalid file descriptor 1028 in syscall close() ==6874== Warning: invalid file descriptor 1029 in syscall close() ==6877== Warning: invalid file descriptor 1024 in syscall close() ==6877== Warning: invalid file descriptor 1025 in syscall close() ==6877== Warning: invalid file descriptor 1026 in syscall close() ==6877== Warning: invalid file descriptor 1027 in syscall close() ==6877== Use --log-fd=<number> to select an alternative log fd. ==6877== Warning: invalid file descriptor 1028 in syscall close() ==6877== Warning: invalid file descriptor 1029 in syscall close() ==6869== Jump to the invalid address stated on the next line ==6869== at 0x2240: ??? ==6869== by 0x40109C9: call_init.part.0 (in /usr/lib64/ld-2.24.so) ==6869== by 0x4010ADA: _dl_init (in /usr/lib64/ld-2.24.so) ==6869== by 0x4015A35: dl_open_worker (in /usr/lib64/ld-2.24.so) ==6869== by 0x4010873: _dl_catch_error (in /usr/lib64/ld-2.24.so) ==6869== by 0x4015008: _dl_open (in /usr/lib64/ld-2.24.so) ==6869== by 0x5525F08: dlopen_doit (in /usr/lib64/libdl-2.24.so) ==6869== by 0x4010873: _dl_catch_error (in /usr/lib64/ld-2.24.so) ==6869== by 0x5526590: _dlerror_run (in /usr/lib64/libdl-2.24.so) ==6869== by 0x5525FA1: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.24.so) ==6869== by 0x4F95D38: _PyImport_FindSharedFuncptr (in /usr/lib64/libpython3.5m.so.1.0) ==6869== by 0x4F7517C: _PyImport_LoadDynamicModuleWithSpec (in /usr/lib64/libpython3.5m.so.1.0) ==6869== Address 0x2240 is not stack'd, malloc'd or (recently) free'd ==6869== ==6869== ==6869== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==6869== Bad permissions for mapped region at address 0x2240 ==6869== at 0x2240: ??? ==6869== by 0x40109C9: call_init.part.0 (in /usr/lib64/ld-2.24.so) ==6869== by 0x4010ADA: _dl_init (in /usr/lib64/ld-2.24.so) ==6869== by 0x4015A35: dl_open_worker (in /usr/lib64/ld-2.24.so) ==6869== by 0x4010873: _dl_catch_error (in /usr/lib64/ld-2.24.so) ==6869== by 0x4015008: _dl_open (in /usr/lib64/ld-2.24.so) ==6869== by 0x5525F08: dlopen_doit (in /usr/lib64/libdl-2.24.so) ==6869== by 0x4010873: _dl_catch_error (in /usr/lib64/ld-2.24.so) ==6869== by 0x5526590: _dlerror_run (in /usr/lib64/libdl-2.24.so) ==6869== by 0x5525FA1: dlopen@@GLIBC_2.2.5 (in /usr/lib64/libdl-2.24.so) ==6869== by 0x4F95D38: _PyImport_FindSharedFuncptr (in /usr/lib64/libpython3.5m.so.1.0) ==6869== by 0x4F7517C: _PyImport_LoadDynamicModuleWithSpec (in /usr/lib64/libpython3.5m.so.1.0) ==6869== ==6869== HEAP SUMMARY: ==6869== in use at exit: 5,576,250 bytes in 43,852 blocks ==6869== total heap usage: 115,115 allocs, 71,263 frees, 18,530,946 bytes allocated ==6869== ==6869== LEAK SUMMARY: ==6869== definitely lost: 0 bytes in 0 blocks ==6869== indirectly lost: 0 bytes in 0 blocks ==6869== possibly lost: 1,701,167 bytes in 14,104 blocks ==6869== still reachable: 3,875,083 bytes in 29,748 blocks ==6869== suppressed: 0 bytes in 0 blocks ==6869== Rerun with --leak-check=full to see details of leaked memory ==6869== ==6869== For counts of detected and suppressed errors, rerun with: -v ==6869== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault (core dumped)
OK, I can reproduce it now. For some reason I had not update R, due to the change in the repos to disable the updates-testing since F25 is coming. As soon as I have updated R then I get the same crash as you do. I am adding Tom in CC since probably this is related with the last change about openblas in R.
That's very odd that it would crash on a symlink. If you make it a hardlink, does it crash?
Creating a hardlink from /usr/lib64/libopenblas.so.0 or /usr/lib64/libopenblas-r0.2.19.so to /usr/lib64/R/lib/libRblas.so doesn't change the error / crash.
Very strange. I'm guessing if you switch libRrefblas.so to libRblas.so, it starts working again?
I removed the symlink "libRblas.so -> /usr/lib64/libopenblas.so.0" and moved libRrefblas.so into place. Still segfaults.
Okay, so this issue has nothing to do with the BLAS in use. That's comforting at least.
When I try to reproduce this on rawhide, I get a different issue: [spot@localhost scratch]$ python3 Python 3.5.2 (default, Oct 17 2016, 12:57:54) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import rpy2 >>> from rpy2 import robjects python3: Relink `/lib64/libsystemd.so.0' with `/lib64/librt.so.1' for IFUNC symbol `clock_gettime' This works on python2 though: [spot@localhost scratch]$ python2 Python 2.7.12 (default, Oct 12 2016, 14:31:21) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import rpy2 >>> from rpy2 import robjects >>>
I have a similar problem with Fedora 24 and VTK, when I import the vtkXMLImageDataReader from vtk (from vtk import vtkXMLImageDataReader) I get the message ImportError: libRblas.so: cannot open shared object file: No such file or directory --------------- importing modules ... Traceback (most recent call last): File "./test.py", line 10, in <module> from vtk import vtkXMLImageDataReader File "/usr/lib64/python2.7/site-packages/vtk/__init__.py", line 102, in <module> from vtkFiltersStatisticsGnuR import * File "/usr/lib64/python2.7/site-packages/vtk/vtkFiltersStatisticsGnuR.py", line 1, in <module> from vtkFiltersStatisticsGnuRPython import * ImportError: libRblas.so: cannot open shared object file: No such file or directory --------------- An export LD_LIBRARY_PATH="/usr/lib64/R/lib/:$LD_LIBRARY_PATH" fixed the problem. Looks like libRblas.so is no longer part of the search path. The problem startet with the version 3.3.2-2 of R-core R-core-3.3.2-2.fc24.x86_64 R-core-devel-3.3.2-2.fc24.x86_64 the version R-core-3.3.0-3.fc24.x86_64 R-core-devel-3.3.0-3.fc24.x86_64 works without problems and without the LD_LIBRARY_PATH fix.
Do you have an /etc/ld.so.conf.d//R-x86_64.conf file?
Yes (version 3.3.2-2) ls -la /etc/ld.so.conf.d/R-x86_64.conf -rw-r--r--. 1 root root 17 31. Okt 21:17 /etc/ld.so.conf.d/R-x86_64.conf more /etc/ld.so.conf.d/R-x86_64.conf /usr/lib64/R/lib (version 3.3.0-3) ls -la /etc/ld.so.conf.d/R-x86_64.conf -rw-r--r--. 1 root root 17 13. Mai 2016 /etc/ld.so.conf.d/R-x86_64.conf more /etc/ld.so.conf.d/R-x86_64.conf /usr/lib64/R/lib (version 3.3.2-2) ls -la /usr/lib64/R/lib total 4972 drwxr-xr-x. 2 root root 4096 14. Dez 14:02 . drwxr-xr-x. 7 root root 4096 14. Dez 14:02 .. lrwxrwxrwx. 1 root root 11 14. Dez 14:02 libopenblas.so.0 -> libRblas.so lrwxrwxrwx. 1 root root 27 31. Okt 21:17 libRblas.so -> /usr/lib64/libopenblas.so.0 -rwxr-xr-x. 1 root root 1989312 31. Okt 21:17 libRlapack.so -rwxr-xr-x. 1 root root 178856 31. Okt 21:17 libRrefblas.so -rwxr-xr-x. 1 root root 2911504 31. Okt 21:17 libR.so ---- ldconfig -p | grep -i libRblas.so <nothing> (version 3.3.0-3) ls -la /usr/lib64/R/lib total 4948 drwxr-xr-x. 2 root root 4096 14. Dez 14:43 . drwxr-xr-x. 7 root root 4096 14. Dez 14:43 .. lrwxrwxrwx. 1 root root 11 13. Dez 13:46 libopenblas.so.0 -> libRblas.so -rwxr-xr-x. 1 root root 178848 13. Mai 2016 libRblas.so -rwxr-xr-x. 1 root root 1964736 13. Mai 2016 libRlapack.so -rwxr-xr-x. 1 root root 2911576 13. Mai 2016 libR.so ---- ldconfig -p | grep -i libRblas.so libRblas.so (libc6,x86-64) => /usr/lib64/R/lib/libRblas.so Somehow libRblas.so is missing in the cache with version 3.3.2-2, version 3.3.0-3 still has /usr/lib64/R/lib/libRblas.so in the cache and yes I forced an update of the cache :-).
I've figured out how to fix this. Details are in https://bugzilla.redhat.com/show_bug.cgi?id=1404662
The fix in Bug #1404662 solved the problem. Thank you!
R-3.3.2-3.fc23 openblas-0.2.19-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-46ffd0fe13
R-3.3.2-3.el7 openblas-0.2.19-4.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-08541f148f
R-3.3.2-3.fc24 openblas-0.2.19-4.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-87243d4214
R-3.3.2-3.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e213692dbc
R-3.3.2-3.fc25 openblas-0.2.19-4.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-3b99079f61
R-3.3.2-3.el5 has been submitted as an update to Fedora EPEL 5. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-11ca20b113
R-3.3.2-3.el7, openblas-0.2.19-4.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-08541f148f
R-3.3.2-3.fc23, openblas-0.2.19-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-46ffd0fe13
R-3.3.2-3.fc24, openblas-0.2.19-4.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-87243d4214
R-3.3.2-3.fc25, openblas-0.2.19-4.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-3b99079f61
R-3.3.2-3.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e213692dbc
R-3.3.2-3.el5 has been pushed to the Fedora EPEL 5 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-11ca20b113
R-3.3.2-3.fc25, openblas-0.2.19-4.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
R-3.3.2-3.fc24, openblas-0.2.19-4.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
R-3.3.2-3.el7, openblas-0.2.19-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
R-3.3.2-3.el5 has been pushed to the Fedora EPEL 5 stable repository. If problems still persist, please make note of it in this bug report.
R-3.3.2-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.