Version-Release number of selected component: dnf-4.2.23-1.fc32 Additional info: reporter: libreport-2.13.1 backtrace_rating: 4 cgroup: 0::/user.slice/user-1000.slice/user/apps.slice/apps-org.gnome.Terminal.slice/vte-spawn-ca5169ef-458d-41cf-a9e3-2a717185da8d.scope cmdline: /usr/bin/python3 /usr/bin/dnf update crash_function: CRYPTO_zalloc executable: /usr/bin/python3.8 journald_cursor: s=f7c16cde027743a2805750727d824692;i=c0300;b=7e4ecf03ae334b5f90dd77f4d160a473;m=8213b505;t=5b038d852753b;x=d4b9ad6c31302d0e kernel: 5.8.10-200.fc32.x86_64 rootdir: / runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #3 CRYPTO_zalloc at crypto/mem.c:230 #4 sk_reserve at crypto/stack/stack.c:180 #5 OPENSSL_sk_insert at crypto/stack/stack.c:242 #6 sk_X509_NAME_ENTRY_push at include/openssl/x509.h:75 #7 x509_name_canon at crypto/x509/x_name.c:345 #9 x509_name_ex_d2i at crypto/x509/x_name.c:191 #10 asn1_item_embed_d2i at crypto/asn1/tasn_dec.c:215 #11 asn1_template_noexp_d2i at crypto/asn1/tasn_dec.c:624 #12 asn1_template_ex_d2i at crypto/asn1/tasn_dec.c:499 #13 asn1_item_embed_d2i at crypto/asn1/tasn_dec.c:363
Created attachment 1719407 [details] File: _var_log_dnf.log
Created attachment 1719408 [details] File: backtrace
Created attachment 1719409 [details] File: core_backtrace
Created attachment 1719410 [details] File: cpuinfo
Created attachment 1719411 [details] File: dnf-makecache.log
Created attachment 1719412 [details] File: dso_list
Created attachment 1719413 [details] File: environ
Created attachment 1719414 [details] File: exploitable
Created attachment 1719415 [details] File: limits
Created attachment 1719416 [details] File: maps
Created attachment 1719417 [details] File: mountinfo
Created attachment 1719418 [details] File: open_fds
Created attachment 1719419 [details] File: proc_pid_status
Hello Patryk, thanks for the report. Are you able to reproduce this reliably or was it one time only? If it was a one-time occurrence, it looks like a rare memory corruption bug we are having and are so far unable to pinpoint. There was, however, a fix in libsolv (in version 7.15) recently that might be a possible culprit. It hasn't been released to Fedora yet, but you can get it from our nightly repo: dnf copr enable rpmsoftwaremanagement/dnf-nightly dnf update libsolv If you are getting the crashes at least semi-regularly and were able to tell us the libsolv upgrade fixed it, that would be a valuable information to us.
Closing for inactivity, if you encounter this again and have more info to share, don't hesitate to reopen. Thanks.