Description of problem: Trying to install updates using PackageKit after being notified of updates. It got about halfway through and promptly threw an error, followed by the crash you see here. As to what else caused it I do not know. At least this time it didn't corrupt the package databases like it usually does. Version-Release number of selected component: PackageKit-0.8.6-1.fc18 Additional info: backtrace_rating: 4 cmdline: /usr/libexec/packagekitd crash_function: zif_md_set_location executable: /usr/libexec/packagekitd kernel: 3.7.1-5.fc18.x86_64 remote_result: NOTFOUND uid: 0 Truncated backtrace: Thread no. 1 (10 frames) #6 zif_md_set_location at zif-md.c:284 #7 zif_store_remote_parser_start_element at zif-store-remote.c:312 #8 emit_start_element at gmarkup.c:983 #9 g_markup_parse_context_parse at gmarkup.c:1320 #10 zif_store_remote_parse_repomd at zif-store-remote.c:1145 #11 zif_store_remote_process_repomd at zif-store-remote.c:1490 #12 zif_store_remote_load_metadata at zif-store-remote.c:1676 #13 zif_store_remote_find_package at zif-store-remote.c:3375 #14 zif_store_find_package at zif-store.c:1761 #15 zif_store_array_find_package at zif-store-array.c:461
Created attachment 677196 [details] File: backtrace
Created attachment 677197 [details] File: build_ids
Created attachment 677198 [details] File: cgroup
Created attachment 677199 [details] File: core_backtrace
Created attachment 677200 [details] File: dso_list
Created attachment 677201 [details] File: environ
Created attachment 677202 [details] File: limits
Created attachment 677203 [details] File: maps
Created attachment 677204 [details] File: open_fds
Created attachment 677205 [details] File: proc_pid_status
Created attachment 677206 [details] File: smolt_data
Created attachment 677207 [details] File: var_log_messages
I stumbed on a similar bug today, it's 100% reproducible running gpk-update-viewer with the zif backend. My crash is in zif_md_set_checksum or zif_md_set_checksum_uncompressed, but the source of error is the same (double free or corruption). The interesting part is that the sources look correct (the variable is initialized to NULL, freed and then set with the return value of strdup()), but it still crashes. Attempting to use MALLOC_PERTURB_=73, I got a crash once inside g_markup_context_free() (for the context used to parse repomds), attempting to double free the string pool used for attributes. My assumption is that glib is correct here, so the reason would be a double free of the GMarkupContext, but once again, the code seems correct. Subsequent tests with the same value of MALLOC_PERTURB_ did not cause the segfault, going back to the previous abort. Also, I got no crash at all under valgrind --tool=memcheck, and not even a bad memory access. Suspecting a race (which would be invisible in valgrind), I tried helgrind and drd, but once again, I had no luck at finding the root of this problem.
In F20 and rawhide the zif backend has been replaced by hawkey.