GNOME Bugzilla – Bug 736362
Core dump due to the assertion failed
Last modified: 2014-09-23 20:56:09 UTC
Created attachment 285774 [details] Copy of the command-line console with the warnings and the final error Please see the copy of the console attached. The critical error line says: Gs:ERROR:gs-app.c:555:gs_app_set_kind: code should not be reached and if you look into gs-app.c:555 you will see this is true: GS_APP_KIND_CORE which has been introduced 7 months ago is missing from the switch instruction. The fix should be easy if one knew what should be the correct behavior when the application's kind is changed from "core" to anything different. It's obvious that this case should be handled because what we have now is a crash because the error could not be handled. The problem happened for the first time when I tried to refresh the updates and now happens *every time* I launch gnome-software, just few seconds after the start. Also I wonder if it is an error or not that I can see so many applications with id set to NULL trying make an illegal change of their kind until an application with kind=="core" is reached causing the core dump. I have introduced an instruction before the line plugins/gs-plugin-packagekit-refine.c:296 (call of gs_plugin_packagekit_resolve_packages_app() ) which skips all applications with id==NULL. I doubt this is a correct solution so I don't post it here but it made my copy of gnome-software run correctly, or at least it seems to me so. My gnome-software version is the most recent git master.
would be good to make this more robust
Hi Rafal, thanks for the report and investigating this. I've pushed https://git.gnome.org/browse/gnome-software/commit/?id=24e4965453c104eb8f65b46e23fafdac4e66a98f which should make it log a warning instead of crashing. Would be nice to figure out the root cause though. Can you 'killall gnome-software' and run it again with 'gnome-software --verbose' and see if it now logs the kind change as a warning and post the log here?
Created attachment 286327 [details] Copy of the command-line console with gnome-software --verbose Hi Kalev, thanks for the commit, at least it does not crash. Please find the log attached, it includes the warning "Gs-WARNING **: Kind change on (null) from core to unknown is not OK" instead of crashing. Also it may be guessed what gnome-software means by "on (null)".
Can you describe your system a little please, for instance, are you enabling and disabling the updates-testing repo between runs?
This is Fedora 21 32-bit installed from an ISO image https://kojipkgs.fedoraproject.org//work/tasks/6450/7466450/Fedora-Live-Workstation-i686-21-20140827.iso with some packages installed later and really few updated. I have not enabled nor disabled any repos, I have had fedora, updates, and updates-testing enabled from the beginning. I have also source code of gnome-software and other required packages downloaded, built and installed locally from git master with jhbuild. Many times I have compiled, launched and killed gnome-software. Could it corrupt any local database? If you want more details, do not hesitate to ask me.
The direct cause of the problem is that pk_client_resolve() returns results for much less packages than passed as the argument. For example, the first call is to resolve the packages: ardour, blender, firefox, gimp, inkscape, mypaint, gnome-weather, transmission, and xchat, as a result only mypaint-data is returned. Most packages are expected to have only 1 source but 0 is returned, thus the applications are being set as unavailable. For other sets of packages the results are also less and this is repeatable: the results are the same for each run. Now the question is: why pk_client_resolve() returns much less results than asked? Is this normal? Is it because of the local database corrupted, software versions mismatch, network problems? Should gnome-software handle this situation more correctly? yum and pkcon resolve these packages with no problems.
We tracked down the cause yesterday; basically this bug is 32bit specific. You can reproduce the problem on the command line with "pkcon resolve firefox --filter=arch" -- libhif treats the arch filter as ==i386 when it should treat it is as ==?86. I've got a sample fix for libhif, but it needs more time so I can actually add a self test so this kind of thing doesn't happen in the future. I should have a fixed build of libhif for you on Monday. This problem has existed since libhif was created, so I think there are probably not many 32 bit testers out there these days.
Moving this off the blocker list, since the crash has been fixed.
I'm really glad to know this.
Fixed with http://koji.fedoraproject.org/koji/buildinfo?buildID=579809 -- thanks for the report!
Now it works perfectly, thank you!