Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1631968 - packagekitd g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Summary: packagekitd g_object_ref: assertion 'G_IS_OBJECT (object)' failed
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: PackageKit
Version: 29
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard Hughes
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-09-22 16:23 UTC by Chris Murphy
Modified: 2018-10-02 19:30 UTC (History)
7 users (show)

Fixed In Version: PackageKit-1.1.11-1.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-02 19:30:45 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)
journal (515.36 KB, text/plain)
2018-09-22 16:28 UTC, Chris Murphy 		no flags Details
View All

Description Chris Murphy 2018-09-22 16:23:02 UTC 
Description of problem:

packagekitd is spewing hundreds of lines (dozens per second)

Sep 22 10:00:29 f29h.local packagekitd[1104]: g_object_ref: assertion 'G_IS_OBJECT (object)' failed




Version-Release number of selected component (if applicable):
PackageKit-1.1.10-4.fc29.x86_64
PackageKit-gtk3-module-1.1.10-4.fc29.x86_64
gtk2-2.24.32-3.fc29.x86_64
gtk3-3.24.1-1.fc29.x86_64


How reproducible:
Appears to happen when refreshing metadata, it's not continuous. Seems like the bigger the update, exponentially more of these messages appear


Steps to Reproduce:
1. boot, wait a while, look in the journal
2.
3.

Actual results:

packagekitd mad/confused, and it's using > 100% CPU but I don't know if the two are related; it's definitely a lot of repetitive spew in the journal.

Expected results:



Additional info:
Comment 1 Chris Murphy 2018-09-22 16:28:18 UTC 
Created attachment 1486016 [details]
journal
Comment 2 Adam Williamson 2018-09-22 18:26:14 UTC 
Wondering if https://github.com/hughsie/PackageKit/pull/278 was possibly related to this? I can't quite tell just from the diff.
Comment 3 Adam Williamson 2018-09-22 18:26:54 UTC 
Aha, no, it looks like it was this:

https://github.com/hughsie/PackageKit/commit/5a74b6c81964893709c5f5620ee78ed73725634e
Comment 4 Fedora Update System 2018-09-22 20:23:02 UTC 
PackageKit-1.1.10-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7c9e62ae82
Comment 5 Kalev Lember 2018-09-22 20:52:06 UTC 
I was deliberately holding off putting this fix in F29. I'll have to unpush the update, otherwise things break when https://github.com/rpm-software-management/libdnf/pull/589 lands.
Comment 6 Adam Williamson 2018-09-22 23:49:00 UTC 
can't we just make sure this is switched back again when that lands? I sent this because people are complaining about the flood of errors, and it seems at least possible it's causing significant CPU usage...
Comment 7 Kalev Lember 2018-09-23 05:29:14 UTC 
I guess so. I didn't want to have a case where updating libdnf would break packagekit, but maybe that's not really much of an issue if we can get new packagekit in before, or together with new libdnf.

In any case, we are going to do a new packagekit release next week to get all the libdnf compat fixes out. I was waiting with the release just to sort this one fix out properly first :)
Comment 8 Adam Williamson 2018-09-23 23:20:25 UTC 
"I didn't want to have a case where updating libdnf would break packagekit, but maybe that's not really much of an issue if we can get new packagekit in before, or together with new libdnf."

That's what I'm saying, yeah. Since Bodhi is on now, we have control over this: all it takes is ensuring we do a PackageKit -6 (which we'll kinda have to do anyway now this build *exists*, even if it's unpushed) and include it in the update along with NM.

If you're planning to get all this done on Monday of course we may as well forget about this update, but if it's gonna take longer than that, maybe we can push it out again. I mean, heck, we can just submit it, and if it's still in testing when the new libdnf and NM are done, we can just edit it and put those builds in instead. I'm a provenpackager, so I have the powers.

Just whatever you do, *don't* submit separate updates for the two, because once that happens, only bowlofeggs can fix it. :P
Comment 9 Fedora Update System 2018-09-23 23:20:45 UTC 
PackageKit-1.1.10-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-7c9e62ae82
Comment 10 Fedora Update System 2018-09-27 02:08:03 UTC 
PackageKit-1.1.11-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-7c9e62ae82
Comment 11 Adam Williamson 2018-09-27 02:51:30 UTC 
Note, PackageKit 1.1.11 actually goes back to the old code here, and compared to 1.1.10-5 will *break* this...unless you also get libdnf 0.20. Unfortunately there are some problems with pulling libdnf 0.20 into F29 right away...
Comment 12 Kalev Lember 2018-09-27 06:26:10 UTC 
That's not true. It should work fine with both the libdnf version in stable and 0.20.0. It leaks a bit of memory with the stable version, but that should be fine since it now shuts down after 300 secs of idle and restarts on demand.
Comment 13 Fedora Update System 2018-10-02 19:30:45 UTC 
PackageKit-1.1.11-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.