Bug 1932228

Summary: leapp and yum segfaults after installing dnf
Product: Red Hat Enterprise Linux 7 Reporter: Christophe Besson <cbesson>
Component: libdnfAssignee: Daniel Mach <dmach>
Status: CLOSED ERRATA QA Contact: Eva Mrakova <emrakova>
Severity: medium Docs Contact:
Priority: high    
Version: 7.9CC: jcastran, pstodulk
Target Milestone: rcKeywords: Extras, Reproducer, Triaged
Target Release: ---Flags: pm-rhel: mirror+
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-04-07 13:56:43 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:
Attachments:
Description Flags
python leapp bt none

Description Christophe Besson 2021-02-24 10:08:21 UTC
Description of problem:
Customer wanted to run an IPU to RHEL 8 with Leapp.
After installing leapp with its dependencies (including dnf), using it leads to a python coredump. Yum segfaults too, and DNF is not usable.

Version-Release number of selected component (if applicable):
# rpm -qa | grep -e leapp -e dnf -e librepo- | grep -v debuginfo
python2-libdnf-0.22.5-2.el7_9.x86_64
leapp-repository-0.13.0-2.el7_9.noarch
dnf-data-4.0.9.2-1.el7_6.noarch
libdnf-0.22.5-2.el7_9.x86_64
dnf-4.0.9.2-1.el7_6.noarch
leapp-deps-0.12.0-1.el7_9.noarch
leapp-repository-deps-0.13.0-2.el7_9.noarch
leapp-0.12.0-1.el7_9.noarch
python2-dnf-4.0.9.2-1.el7_6.noarch
python2-leapp-0.12.0-1.el7_9.noarch
librepo-1.7.16-1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Install a fully updated RHEL 7.9 system
2. Downgrade to librepo-1.7.16-1.el7.x86_64 to match the customer environment
3. Install Leapp (which comes with DNF/libdnf from RHEL 7 extras)

Actual results:
~~~
# yum 
Segmentation fault

# dnf repolist
Traceback (most recent call last):
  File "/usr/bin/dnf", line 57, in <module>
    from dnf.cli import main
  File "/usr/lib/python2.7/site-packages/dnf/__init__.py", line 30, in <module>
    import dnf.base
  File "/usr/lib/python2.7/site-packages/dnf/base.py", line 29, in <module>
    import libdnf.transaction
  File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in <module>
    from . import conf
  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 18, in <module>
    _conf = swig_import_helper()
  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in swig_import_helper
    return importlib.import_module('_conf')
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: No module named _conf

# dmesg | grep segfault
[  113.872447] leapp[5312]: segfault at 22346 ip 0000000000022346 sp 00007ffeb9e4f878 error 14 in python2.7[400000+1000]
[  125.647917] yum[6731]: segfault at 22346 ip 0000000000022346 sp 00007ffcdd052fc8 error 14 in python2.7[400000+1000]
~~~

Expected results:
Leapp, Yum and DNF does not crash.

Additional info:
* Filed this bug against libdnf because I don't see an explicit dependency to librepo with the required version, possibly move it to another component if needed.

* Updating the latest librepo thanks to the rpm command fixes the issue.

* Yum is broken because it reads the libdnf python wrapper once it is installed:
~~~
793   01:49:02.233940 open("/usr/lib64/python2.7/site-packages/libdnf/_conf.so", O_RDONLY) = 12</usr/lib64/python2.7/site-packages/libdnf/_conf.so> <0.000042>
793   01:49:02.234043 fstat(12</usr/lib64/python2.7/site-packages/libdnf/_conf.so>, {st_dev=makedev(253, 5), st_ino=138173, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=1480, st_size=757672, st_atime=1613639579 /* 2021-02-18T20:12:59.514170989+1100 */, st_atime_nsec=514170989, st_mtime=1586967955 /* 2020-04-16T02:25:55+1000 */, st_mtime_nsec=0, st_ctime=1612947079 /* 2021-02-10T19:51:19.305955772+1100 */, st_ctime_nsec=305955772}) = 0 <0.000034>
793   01:49:02.234199 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x22346} ---
793   01:49:02.428556 +++ killed by SIGSEGV (core dumped) +++
~~~

* Issue seen in Python:
~~~
# python
Python 2.7.5 (default, Aug 13 2020, 02:51:10) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib
>>> importlib.import_module('libdnf._conf')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/usr/lib64/python2.7/site-packages/libdnf/__init__.py", line 3, in <module>
    from . import conf
  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 17, in <module>
    _conf = swig_import_helper()
  File "/usr/lib64/python2.7/site-packages/libdnf/conf.py", line 16, in swig_import_helper
    return importlib.import_module('_conf')
  File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
ImportError: No module named _conf
~~~

* Same with the latest librepo
~~~
# python
Python 2.7.5 (default, Aug 13 2020, 02:51:10) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import importlib
>>> importlib.import_module('libdnf._conf')
<module 'libdnf._conf' from '/usr/lib64/python2.7/site-packages/libdnf/_conf.so'>
~~~

Comment 2 Christophe Besson 2021-02-24 10:11:49 UTC
Created attachment 1759037 [details]
python leapp bt

likely not useful

Comment 3 Daniel Mach 2021-02-25 09:40:38 UTC
Is there a reason why librepo couldn't be upgraded to the latest version?
librepo-1.8.1-7.el7 should be the latest available.

Comment 13 errata-xmlrpc 2021-04-07 13:56:43 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (nextgen-yum4 bug fix update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:1130