After a crash in control-center, I chose to download debuginfo packages rather than upload a core dump. But the process got a useless backtrace because of this failure: --- Running analyze_CCpp --- Ok to upload core dump? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. (It may download a huge amount of data). 'NO' Analyzing coredump 'coredump' Coredump references 268 debuginfo files, 268 of them are not installed Setting up yum repositories Looking for needed packages in repositories Can't find packages for 8 debuginfo files Packages to download: 129 Downloading 390.86Mb, installed size: 1753.21Mb. Continue? 'YES' Downloading (1 of 129) libXrender-debuginfo-0.9.8-4.fc21.x86_64.rpm: 100% Extracting cpio from /var/tmp/abrt-tmp-debuginfo-2015-04-20-12:39:38.8149/libXrender-debuginfo-0.9.8-4.fc21.x86_64.rpm Caching files from unpacked.cpio made from libXrender-debuginfo-0.9.8-4.fc21.x86_64.rpm Can't extract files from '/var/tmp/abrt-tmp-debuginfo-2015-04-20-12:39:38.8149/unpacked.cpio' Unpacking failed, aborting download... This is similar to Bug 1169774 and Bug 1036918.
Thank you for taking the time to report this bug. If you have a moment, can you install this scratch packages of libreport http://koji.fedoraproject.org/koji/taskinfo?taskID=9547360? After unpacking failure there will be a cpio unpacking log file in '/tmp' with 'abrt-unpacking-' prefix. The exact name of the log file you can find in gnome-abrt logging (for example: "Can't extract files from '/var/tmp/abrt-tmp-debuginfo-2015-04-20-12:39:38.8149/unpacked.cpio'. For more information see '/tmp/abrt-unpacking-XXXXX'"). The 'abrt-unpacking-XXXXX is the log file. Can you post here a content of the log file?
OK, I now have the following installed: libreport-2.3.0-6.1169774.fc21.x86_64 libreport-anaconda-2.3.0-6.1169774.fc21.x86_64 libreport-cli-2.3.0-6.1169774.fc21.x86_64 libreport-fedora-2.3.0-6.1169774.fc21.x86_64 libreport-filesystem-2.3.0-6.1169774.fc21.x86_64 libreport-gtk-2.3.0-6.1169774.fc21.x86_64 libreport-plugin-bugzilla-2.3.0-6.1169774.fc21.x86_64 libreport-plugin-kerneloops-2.3.0-6.1169774.fc21.x86_64 libreport-plugin-logger-2.3.0-6.1169774.fc21.x86_64 libreport-plugin-reportuploader-2.3.0-6.1169774.fc21.x86_64 libreport-plugin-ureport-2.3.0-6.1169774.fc21.x86_64 libreport-python-2.3.0-6.1169774.fc21.x86_64 libreport-python3-2.3.0-6.1169774.fc21.x86_64 libreport-web-2.3.0-6.1169774.fc21.x86_64 New log: --- Running report_uReport --- ('report_uReport' completed successfully) --- Running analyze_CCpp --- Ok to upload core dump? (It may contain sensitive data). If your answer is 'No', a stack trace will be generated locally. (It may download a huge amount of data). 'NO' Analyzing coredump 'coredump' Coredump references 258 debuginfo files, 258 of them are not installed Setting up yum repositories Looking for needed packages in repositories Can't find packages for 2 debuginfo files Packages to download: 127 Downloading 385.38Mb, installed size: 1730.07Mb. Continue? 'YES' Downloading (1 of 127) icu-debuginfo-52.1-6.fc21.x86_64.rpm: 100% Extracting cpio from /var/tmp/abrt-tmp-debuginfo-2015-04-29-12:41:52.15404/icu-debuginfo-52.1-6.fc21.x86_64.rpm Caching files from unpacked.cpio made from icu-debuginfo-52.1-6.fc21.x86_64.rpm Can't download debuginfos: local variable 'log_file_name' referenced before assignment Generating backtrace Backtrace is generated and saved, 39978 bytes Looking for similar problems in bugzilla I see /var/tmp/abrt-tmp-debuginfo-2015-04-29-12:41:52.15404/ but there are no abrt directories or files in /tmp and nothing with "unpacking" in the name in /var/tmp. There is an unpacked.cpio file in that directory, which I'll attach.
Created attachment 1020263 [details] /var/tmp/abrt-tmp-debuginfo-2015-04-29-12:41:52.15404/unpacked.cpio (after bzip2 to fit under max upload size)
I am sorry, the patches I added to f21 scratch build don't work well on f21. I've created a new scratch build for f21 which should work better: http://koji.fedoraproject.org/koji/taskinfo?taskID=9605174 Can you install the scratch build's packages and try it again, please? Can you also run this command 'ls -ldZ /var/cache/abrt-di/{,usr/{,lib/{,debug}}}' and post the output? Thank you!
Created attachment 1020668 [details] Requested info from second round of testing OK, that worked as expected this time. Attaching the results.
Thank you for the great analysis. '/var/cache/abrt-di/' should not be owned by root but by abrt. Can you run '# chown -R abrt.abrt /var/cache/abrt-di/' and try it again?
Aha! I had erased everything in /var/cache/ because the Filesystem Hierarchy Standard (http://www.pathname.com/fhs/pub/fhs-2.3.html) says: "Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage)." But /var/cache/abrt-di/ is created by the installation of the abrt-addon-ccpp-2.3.0-4.fc21.x86_64 RPM. When I'm trying to report the control-center crash, I'm running as user beland, so I can see why abrt is having trouble recovering, as /var/cache is owned by root. It would be nice if abrt could recover more gracefully from this situation, either by asking for an administrator password so it can recreate the directory, putting its downloaded data somewhere it *can* access, or at least giving a clearer error message. After doing: sudo mkdir /var/cache/abrt-di/ sudo chown -R abrt.abrt /var/cache/abrt-di/ I was able to report Bug 1219606 normally.
I've created a pull request which fixes the bug: https://github.com/abrt/libreport/pull/349 If unpacking of debuginfo fails and '/vat/cache/abrt-di' is not owned by abrt.abrt the client provides a solution how to fix the issue: "'/var/cache/abrt-di' must be owned by abrt. Please run '# chown -R abrt.abrt /var/cache/abrt-di' to fix the issue."
gnome-abrt-1.0.0-2.fc21,abrt-2.3.0-5.fc21,libreport-2.3.0-7.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/gnome-abrt-1.0.0-2.fc21,abrt-2.3.0-5.fc21,libreport-2.3.0-7.fc21
Package gnome-abrt-1.0.0-2.fc21, abrt-2.3.0-6.fc21, libreport-2.3.0-8.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 gnome-abrt-1.0.0-2.fc21 abrt-2.3.0-6.fc21 libreport-2.3.0-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10193/gnome-abrt-1.0.0-2.fc21,abrt-2.3.0-6.fc21,libreport-2.3.0-8.fc21 then log in and leave karma (feedback).
Package gnome-abrt-1.0.0-3.fc21, abrt-2.3.0-7.fc21, libreport-2.3.0-8.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 gnome-abrt-1.0.0-3.fc21 abrt-2.3.0-7.fc21 libreport-2.3.0-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-10193/gnome-abrt-1.0.0-3.fc21,abrt-2.3.0-7.fc21,libreport-2.3.0-8.fc21 then log in and leave karma (feedback).
gnome-abrt-1.0.0-3.fc21, abrt-2.3.0-7.fc21, libreport-2.3.0-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.