Bug 1392192 - segfault during normal usage
Summary: segfault during normal usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpy
Version: 25
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: José Matos
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-05 21:10 UTC by Fabio Valentini
Modified: 2017-01-07 00:19 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-19 06:03:23 UTC


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.