Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1392192
Summary: | segfault during normal usage | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Fabio Valentini <decathorpe> |
Component: | rpy | Assignee: | José Matos <jamatos> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 25 | CC: | 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
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. |