Version-Release number of selected component: PackageKit-0.9.4-4.fc21 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: /usr/libexec/packagekitd crash_function: hy_repo_get_string executable: /usr/libexec/packagekitd kernel: 3.17.0-0.rc2.git2.1.fc22.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #0 hy_repo_get_string at /usr/src/debug/hawkey/py3/src/repo.c:200 #1 load_yum_repo at /usr/src/debug/hawkey/py3/src/sack.c:548 #2 hy_sack_load_yum_repo at /usr/src/debug/hawkey/py3/src/sack.c:980 #3 hif_sack_add_source at hif-sack.c:109 #4 hif_sack_add_sources at hif-sack.c:154 #5 hif_context_setup_sack at hif-context.c:803 #6 hif_context_setup at hif-context.c:912 #7 pk_backend_initialize at pk-backend-hif.c:203 #8 pk_backend_load at pk-backend.c:588 #9 pk_engine_load_backend at pk-engine.c:1059 Potential duplicate: bug 1066170
Created attachment 933027 [details] File: backtrace
Created attachment 933028 [details] File: cgroup
Created attachment 933029 [details] File: core_backtrace
Created attachment 933030 [details] File: dso_list
Created attachment 933031 [details] File: environ
Created attachment 933032 [details] File: exploitable
Created attachment 933033 [details] File: limits
Created attachment 933034 [details] File: maps
Created attachment 933035 [details] File: open_fds
Created attachment 933036 [details] File: proc_pid_status
Created attachment 933037 [details] File: var_log_messages
Looks like a hawkey crash. Reassigning.
Thread 1, frame #2 - PackageKit called hy_sack_load_yum_repo with NULL repo parameter. -> reassigning back to Packagekit.
*** Bug 1066170 has been marked as a duplicate of this bug. ***
Another user experienced a similar problem: Initial system start. reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/libexec/packagekitd crash_function: hy_repo_get_string executable: /usr/libexec/packagekitd kernel: 3.17.7-300.fc21.x86_64 package: PackageKit-1.0.3-4.fc21 reason: packagekitd killed by SIGSEGV runlevel: N 3 type: CCpp uid: 0
Another user experienced a similar problem: Packagekitd just crashed itself. reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/libexec/packagekitd crash_function: hy_repo_get_string executable: /usr/libexec/packagekitd kernel: 3.17.7-300.fc21.x86_64 package: PackageKit-1.0.3-4.fc21 reason: packagekitd killed by SIGSEGV runlevel: N 5 type: CCpp uid: 0
Another user experienced a similar problem: It happened during startup. reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/libexec/packagekitd crash_function: hy_repo_get_string executable: /usr/libexec/packagekitd kernel: 3.17.8-300.fc21.i686 package: PackageKit-1.0.3-4.fc21 reason: packagekitd killed by SIGSEGV runlevel: N 5 type: CCpp uid: 0
Another user experienced a similar problem: PackageKit keeps crashing without apparent reason. reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/libexec/packagekitd crash_function: hy_repo_get_string executable: /usr/libexec/packagekitd kernel: 3.17.8-300.fc21.i686 package: PackageKit-1.0.3-4.fc21 reason: packagekitd killed by SIGSEGV runlevel: N 5 type: CCpp uid: 0
Just saw this too on an F21 system, looks to happen when I launch Software; I can restart packagekit.service and see it running, launch Software, and it crashes. I had some issues with offline updates just prior to encountering this.
hum - this seems to be 100%
This seems to be 100% reproducible for me ATM - I can trigger it every time by launching gnome-software, even after a 'pkcon repair' and a reboot.
Looking through the code and the backtrace I've got a theory that I caused this by doing: rm -f /etc/yum.repos.d/fedora-rawhide-kernel-nodebug.repo because I didn't want to use that repo any more. I suspect that hawkey and/or hif still know about that repo somehow, so they're trying to set it up. It seems plausible that the hif_source_get_repo (src) call in hif_sack_add_source() might return null in this case, then we wind up calling hy_sack_load_repo() with a null second parameter. I'm not sure where to check and see what repos hawkey/hif 'think' exist, though. I don't know where they get that information.
OK, yeah, I'm starting to like my theory. My backtrace does end up in the same problem, but it comes down a different path: #8 0x00007f91b8db1eda in pk_backend_job_thread_setup (thread_data=0x7f91bb267ab0) at pk-backend-job.c:815 #7 0x00007f91ad35cf07 in pk_backend_search_thread (job=0x7f91bb260370 [PkBackendJob], params=<optimized out>, user_data=<optimized out>) at pk-backend-hif.c:899 #6 0x00007f91ad35bcfe in hif_utils_create_sack_for_filters (job=job@entry=0x7f91bb260370 [PkBackendJob], filters=<optimized out>, create_flags=<optimized out>, create_flags@entry=HIF_CREATE_SACK_FLAG_USE_CACHE, state=0x7f91bb017400 [HifState], error=error@entry=0x7f91927c5da8) at pk-backend-hif.c:678 #5 0x00007f91ad35bcfe in hif_utils_create_sack_for_filters (error=0x7f91927c5da8, state=<optimized out>, flags=13, sack=0x7f918c1a1410, job=0x7f91bb260370 [PkBackendJob]) at pk-backend-hif.c:490 #4 0x00007f91accf7ee4 in hif_sack_add_sources (sack=sack@entry=0x7f918c1a1410, sources=0x7f91bafd4e40, permissible_cache_age=4294967295, flags=flags@entry=13, state=state@entry=0x7f91bb017240 [HifState], error=error@entry=0x7f91927c5da8) at hif-sack.c:160 #3 0x00007f91accf7d8e in hif_sack_add_source (sack=sack@entry=0x7f918c1a1410, src=src@entry=0x7f91bb17a2f0 [HifSource], permissible_cache_age=permissible_cache_age@entry=4294967295, flags=flags@entry=13, state=0x7f91bb205f90 [HifState], error=error@entry=0x7f91927c5da8) at hif-sack.c:109 #2 0x00007f91acade39d in hy_sack_load_yum_repo (sack=sack@entry=0x7f918c1a1410, repo=0x0, flags=flags@entry=3) at /usr/src/debug/hawkey/py3/src/sack.c:980 #1 0x00007f91acade39d in hy_sack_load_yum_repo (hrepo=0x0, sack=0x7f918c1a1410) at /usr/src/debug/hawkey/py3/src/sack.c:548 So looking in hif_utils_create_sack_for_filters() it's clear that it will use a cached 'sack' sometimes. In /var/cache/PackageKit/hif/ I see some very cache-y looking bits, including: fedora-rawhide-kernel-nodebug.solv though it's rather old: "Sep 21 22:27" but in /var/cache/PackageKit/hawkey there's some similar bits, much newer: Jan 21 07:01 fedora-rawhide-kernel-nodebug.solv so my bet here is that this code path isn't safe when a repo has been deleted out from under it; the cached sack has a source backed by a repo that doesn't actually exist any more, so when hif_source_get_repo() is called on that source the result is null, and that gets passed to hy_sack_load_repo(), causing the crash.
So I figured moving /var/cache/PackageKit/hawkey out of the way, restarting packagekit.service, and running gnome-software would work around this bug, but actually, it seems to cause the same crash. Richard's going to look into it further on Monday.
I easily reproduced this with this repo file: http://paste.fedoraproject.org/180902/29755291/ It seems it's enough when you point a repo with file:// baseurl into a nonexistent directory.
commit 43188b72c5b88e0ec427dc0b24acae5f91c72390 Author: Richard Hughes <richard> Date: Tue Feb 3 15:15:49 2015 +0000 If the enabled local source does not exist do not add it to the sack You can reproduce the problem setting baseurl=file:///notgoingtoexist in an enabled .repo file. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1135740 Builds here: http://koji.fedoraproject.org/koji/taskinfo?taskID=8810185
libhif-0.1.8-3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/libhif-0.1.8-3.fc21
Package libhif-0.1.8-4.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing libhif-0.1.8-4.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-1644/libhif-0.1.8-4.fc21 then log in and leave karma (feedback).
libhif-0.1.8-4.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1247753 has been marked as a duplicate of this bug. ***