Bug 1636657

Summary: [abrt] PackageKit: strrchr(): packagekitd killed by SIGSEGV
Product: [Fedora] Fedora Reporter: François Perriot <francois.perriot>
Component: libdnfAssignee: Jaroslav Mracek <jmracek>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 29CC: dmach, jmracek, jonathan, jorti, klember, mluscon, rdieter, rhughes, rpm-software-management, smparrish
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
URL: https://retrace.fedoraproject.org/faf/reports/bthash/551717117f44b51747a314cd38271237b7b066f3
Whiteboard: abrt_hash:1f862d6568ad7eaa4db119738eeea8a0333903f4;VARIANT_ID=workstation;
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-09-27 08:48:18 UTC Type: ---
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
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: cpuinfo
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: mountinfo
none
File: open_fds
none
File: proc_pid_status
none
File: var_log_messages none

Description François Perriot 2018-10-06 10:03:23 UTC
Version-Release number of selected component:
PackageKit-1.1.11-1.fc29

Additional info:
reporter:       libreport-2.9.5
backtrace_rating: 4
cmdline:        /usr/libexec/packagekitd
crash_function: strrchr
executable:     /usr/libexec/packagekitd
journald_cursor: s=f7d0a61bac274277bf5139dcc74314a4;i=15633;b=18533594372f4ac8b705170f17219d54;m=b64c1a6;t=57766dfb8798d;x=54127557aaddde8f
kernel:         4.18.11-301.fc29.x86_64
rootdir:        /
runlevel:       N 5
type:           CCpp
uid:            0

Comment 1 François Perriot 2018-10-06 10:03:31 UTC
Created attachment 1491007 [details]
File: backtrace

Comment 2 François Perriot 2018-10-06 10:03:32 UTC
Created attachment 1491009 [details]
File: cgroup

Comment 3 François Perriot 2018-10-06 10:03:33 UTC
Created attachment 1491011 [details]
File: core_backtrace

Comment 4 François Perriot 2018-10-06 10:03:35 UTC
Created attachment 1491013 [details]
File: cpuinfo

Comment 5 François Perriot 2018-10-06 10:03:36 UTC
Created attachment 1491015 [details]
File: dso_list

Comment 6 François Perriot 2018-10-06 10:03:38 UTC
Created attachment 1491017 [details]
File: environ

Comment 7 François Perriot 2018-10-06 10:03:40 UTC
Created attachment 1491018 [details]
File: exploitable

Comment 8 François Perriot 2018-10-06 10:03:41 UTC
Created attachment 1491020 [details]
File: limits

Comment 9 François Perriot 2018-10-06 10:03:44 UTC
Created attachment 1491022 [details]
File: maps

Comment 10 François Perriot 2018-10-06 10:03:45 UTC
Created attachment 1491024 [details]
File: mountinfo

Comment 11 François Perriot 2018-10-06 10:03:47 UTC
Created attachment 1491027 [details]
File: open_fds

Comment 12 François Perriot 2018-10-06 10:03:48 UTC
Created attachment 1491028 [details]
File: proc_pid_status

Comment 13 François Perriot 2018-10-06 10:03:50 UTC
Created attachment 1491029 [details]
File: var_log_messages

Comment 14 Kalev Lember 2018-10-31 10:19:47 UTC
Looks like a crash in libdnf. Reassigning.

Comment 15 Jaroslav Mracek 2019-09-12 11:23:55 UTC
I am so sorry for late response. Is there any chance to get additional information? 
Like did you experience the issue only once or multiple times, or are you still able to reproduce the issue?


What is visible from the report: crashed with libdnf-0.20.0-1.fc29

The crash appeared after call dnf_sack.cpp/load_ext(): solv_xfopen (fn=fn@entry=0x642f2f3a73707474 <error: Cannot access memory at address 0x642f2f3a73707474>, mode=mode@entry=0x7ffbae66a093 "r") at ../ext/solv_xfopen.c:550

At the present time in Fedora 30 there is available libdnf-0.35.2. The new version provides a lot of improvements in stability, therefore the issue could be already fixed.

Comment 16 Jaroslav Mracek 2019-09-27 08:48:18 UTC
Without additional information we cannot do much. Please feel free to reopen the bug report with additional information about the issue.

Comment 17 François Perriot 2020-05-08 08:16:25 UTC
Can be closed