Bug 1460303

Created attachment 1286452 [details]
File: backtrace

Created attachment 1286453 [details]
File: cgroup

Created attachment 1286454 [details]
File: core_backtrace

Created attachment 1286455 [details]
File: dso_list

Created attachment 1286456 [details]
File: environ

Created attachment 1286457 [details]
File: exploitable

Created attachment 1286458 [details]
File: limits

Created attachment 1286459 [details]
File: maps

Created attachment 1286460 [details]
File: mountinfo

Created attachment 1286461 [details]
File: namespaces

Created attachment 1286462 [details]
File: open_fds

Created attachment 1286463 [details]
File: proc_pid_status

Created attachment 1286464 [details]
File: var_log_messages

Fortunately, rpm --rebuilddb fixes it.

Similar problem has been detected:

Unable to complete system update

reporter:       libreport-2.8.0
backtrace_rating: 4
cmdline:        /usr/libexec/system-python /bin/dnf update --refresh
crash_function: __env_in_api
executable:     /usr/libexec/system-python
global_pid:     43698
kernel:         4.11.3-200.fc25.x86_64
package:        system-python-3.5.3-6.fc25
pkg_fingerprint: 4089 D8F2 FDB1 9C98
pkg_vendor:     Fedora Project
reason:         system-python killed by SIGSEGV
runlevel:       N 5
type:           CCpp
uid:            0

*** Bug 1460379 has been marked as a duplicate of this bug. ***

This crash is *after* the libdb update which ended up in dnf crashing first time, right? 

The backtrace shows dnf is in early init stage here, reading config file and figuring distro version, which it certainly should not be doing when it's just about to close shop for the day after printing out "Complete!". 

Switching component to libdb as that's where it's crashing.

Most of the discussion for this takes place over in https://bugzilla.redhat.com/show_bug.cgi?id=1394862 as the fix for that bug introduced this failure.

(In reply to Panu Matilainen from comment #17)
> This crash is *after* the libdb update which ended up in dnf crashing first
> time, right? 
> 
> The backtrace shows dnf is in early init stage here, reading config file and
> figuring distro version, which it certainly should not be doing when it's
> just about to close shop for the day after printing out "Complete!". 
> 
> Switching component to libdb as that's where it's crashing.

Correct, this is the crash that happened when I tried to run `dnf update' again afterwards. abrt wasn't able to get a usable stack trace from the first crash in the final stage of the libdb update.

It looks like this happened to me because I have the tracer plugin installed:

python3-dnf-plugins-extras-tracer-0.0.12-4.fc25.noarch
python3-tracer-0.6.12-4.fc25.noarch
tracer-common-0.6.12-4.fc25.noarch

Thanks Dominik for pointing out the issue is with the tracer plugin.

After looking into this some more I have found out this issue will not be possible to mitigate unfortunately. The segfault happens because a posttransaction dnf plugin tries to access the rpmdb in some way and rpmdb's environment is rebuilt along the way.

The segfault happening past the first crash is a result of libdb's fault management system that tries to log any errors hit when inside libdb's functions. However, as the older version of libdb (with older internal structure representation) is the one that creates the fault report and the new version of libdb is the one that reads it, another segfault is hit when trying to access the details of the first hang. Any further hangs should provide the user with proper error messages.

Fortunately this only becomes an issue when upgrading from an older release of libdb (older than libdb-5.3.28-21) and only once as release 21 (and newer) introduce additional locks on the environment to make sure any such crashes cannot happen (the plugin will still fail when unable to access the environment though).

I will leave this bug open for now so that people can find this information more easily.

This should hopefully be already fixed by band-aids applied to rpm and libsolv.