Bug 1392192

Summary: segfault during normal usage
Product: [Fedora] Fedora Reporter: Fabio Valentini <decathorpe>
Component: rpyAssignee: José Matos <jamatos>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 25CC: alex, igeorgex, jamatos, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-19 06:03:23 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Fabio Valentini 2016-11-05 21:10:49 UTC 
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
Comment 1 José Matos 2016-11-07 10:09:53 UTC 
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
Comment 2 Fabio Valentini 2016-11-07 14:26:02 UTC 
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.
Comment 3 Fabio Valentini 2016-11-07 14:28:52 UTC 
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)
Comment 4 José Matos 2016-11-10 09:56:12 UTC 
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.
Comment 5 Tom "spot" Callaway 2016-11-10 19:23:42 UTC 
That's very odd that it would crash on a symlink. If you make it a hardlink, does it crash?
Comment 6 Fabio Valentini 2016-11-11 08:15:10 UTC 
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.
Comment 7 Tom "spot" Callaway 2016-11-11 14:17:57 UTC 
Very strange. I'm guessing if you switch libRrefblas.so to libRblas.so, it starts working again?
Comment 8 Fabio Valentini 2016-11-11 15:07:55 UTC 
I removed the symlink "libRblas.so -> /usr/lib64/libopenblas.so.0" and moved libRrefblas.so into place. Still segfaults.
Comment 9 Tom "spot" Callaway 2016-11-11 15:09:30 UTC 
Okay, so this issue has nothing to do with the BLAS in use. That's comforting at least.
Comment 10 Tom "spot" Callaway 2016-11-15 19:31:18 UTC 
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
>>>
Comment 11 JM 2016-12-14 14:56:20 UTC 
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.
Comment 12 Tom "spot" Callaway 2016-12-14 15:09:19 UTC 
Do you have an /etc/ld.so.conf.d//R-x86_64.conf file?
Comment 13 JM 2016-12-14 15:16:34 UTC 
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 :-).
Comment 14 Tom "spot" Callaway 2016-12-14 17:09:11 UTC 
I've figured out how to fix this. Details are in https://bugzilla.redhat.com/show_bug.cgi?id=1404662
Comment 15 JM 2016-12-14 17:23:09 UTC 
The fix in Bug #1404662 solved the problem. Thank you!
Comment 16 Fedora Update System 2016-12-15 17:32:08 UTC 
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
Comment 17 Fedora Update System 2016-12-15 17:32:29 UTC 
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
Comment 18 Fedora Update System 2016-12-15 17:32:41 UTC 
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
Comment 19 Fedora Update System 2016-12-15 17:32:52 UTC 
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
Comment 20 Fedora Update System 2016-12-15 17:33:04 UTC 
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
Comment 21 Fedora Update System 2016-12-15 17:33:17 UTC 
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
Comment 22 Fedora Update System 2016-12-16 04:23:00 UTC 
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
Comment 23 Fedora Update System 2016-12-16 05:26:58 UTC 
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
Comment 24 Fedora Update System 2016-12-16 05:32:08 UTC 
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
Comment 25 Fedora Update System 2016-12-16 05:34:11 UTC 
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
Comment 26 Fedora Update System 2016-12-16 13:17:35 UTC 
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
Comment 27 Fedora Update System 2016-12-16 13:18:01 UTC 
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
Comment 28 Fedora Update System 2016-12-19 06:03:23 UTC 
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.
Comment 29 Fedora Update System 2017-01-04 21:21:45 UTC 
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.
Comment 30 Fedora Update System 2017-01-05 04:19:56 UTC 
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.
Comment 31 Fedora Update System 2017-01-06 23:48:27 UTC 
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.
Comment 32 Fedora Update System 2017-01-07 00:19:11 UTC 
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.