Created attachment 1714610 [details] screenshot Description of problem: gnome-abrt doesn't do local processing of crashes; doesn't offer to file a bug report. Version-Release number of selected component (if applicable): gnome-abrt-1.3.6-4.fc33.x86_64 abrt-2.14.4-4.fc33.x86_64 libreport-2.14.0-7.fc33.x86_64 How reproducible: Always as far as I can tell Steps to Reproduce: 1. Launch an app, e.g. rhythmbox 2. kill -ABRT $rhythmboxpid 3. Actual results: Crash is reported in gnome-abrt, but it says processing failed and doesn't offer local generation of a stack trace for upload+bug filing assistance. Expected results: Offer to do local processing, download a bunch of debuginfos, and submit a bug report with the proper attachments. Additional info:
Might be a dup of bug 1873029. Filing a new bug because the message in gnome-abrt is different.
There's a ccpp directory full of stuff. coredumpctl gdb is willing to process it. abrt-cli refuses to try to report it due to the retrace server not responding.
Proposed as a Blocker for 33-final by Fedora user chrismurphy using the blocker tracking app because: Final: All applications that can be launched using the standard graphical mechanism after a default installation of Fedora Workstation on the x86_64 architecture must start successfully and withstand a basic functionality test. - problem reporter
I guess since both gui and cli reporters don't seem to be willing or able to report to RHBZ, it could also be argued the catch-all applies from bullet #2: https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria#Beta_Blocker_Bugs * Bug hinders execution of required Beta test plans or dramatically reduces test coverage
(In reply to Chris Murphy from comment #4) > * Bug hinders execution of required Beta test plans or dramatically reduces > test coverage Yes, this should be a beta blocker.
Discussed during the 2020-09-14 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker" was made on the grounds that it "hinders execution of required Beta test plans or dramatically reduces test coverage", like the other similar bugs. We will sort out which bugs do and don't exist with which updates after the meeting. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-09-14/f33-blocker-review.2020-09-14-16.01.txt
Regarding the blocker bug, let me reprint my reasoning here: "Also please note I'm voting for a blocker with a requirement that ABRT must be able to report a bug. Whether it allows a local tracing or remote tracing is, I believe, an implementation detail. But at least one option must work (and the other option must not be very prominently broken, that would make it seem as a basic functionality)." https://pagure.io/fedora-qa/blocker-review/issue/86#comment-685491 If ABRT is able to report a bug, in any way (local or remote tracing), I believe that's completely sufficient for Beta.
I can confirm this problem when I have the following update installed: https://bodhi.fedoraproject.org/updates/FEDORA-2020-444a3363f0 meaning: abrt-2.14.4-5.fc33.x86_64 gnome-abrt-1.3.6-5.fc33.x86_64 libreport-2.14.0-8.fc33.x86_64 The error message is exactly the same as in attachment 1714610 [details].
For the record I agree with Kamil's reasoning from #c7 here.
So there's a really simple/dumb thing you can do to see what happens: edit all the files in /usr/share/libreport/workflows/ and remove the <event>report_uReport</event> lines from them. (Then maybe restart abrtd.service, I don't know whether it's necessary so I did it). For me that causes abrt-cli to skip the report_uReport step and try to report my crash, which is good. But then I get this, which is bad: Packages to download: 3 Downloading 23.29Mb, installed size: 163.55Mb. Continue? [y/N] y Downloading (1 of 3) glibc-debuginfo-2.32-1.fc33.x86_64.rpm: 100% Extracting cpio from /var/tmp/dnf-adamw-a9q5lmux/fedora-debuginfo-85d473e83a9b48cd/packages/glibc-debuginfo-2.32-1.fc33.x86_64.rpm Caching files from unpacked.cpio made from glibc-debuginfo-2.32-1.fc33.x86_64.rpm Can't extract files from '/var/tmp/abrt-tmp-debuginfo.u6YV8N/unpacked.cpio'. For more information see '/tmp/abrt-unpacking-8t3lvzq1' Unpacking failed, aborting download... Can't download debuginfos: [Errno 1] Operation not permitted: '/var/cache/abrt-di/usr' The /tmp file referenced shows lots of lines like this: cpio: ./usr/lib/debug/.build-id: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/00: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/01: Cannot change mode to rwxr-xr-x: Operation not permitted cpio: ./usr/lib/debug/.build-id/02: Cannot change mode to rwxr-xr-x: Operation not permitted for various directories and files. I'd be curious to see what results other folks get with this tweak...
oh, and with that change, gnome-abrt behaves like https://bugzilla.redhat.com/show_bug.cgi?id=1873029 for me. Even with gnome-abrt-1.3.6-5.fc33.x86_64 and all other packages from https://bodhi.fedoraproject.org/updates/FEDORA-2020-444a3363f0 . odd.
So I tried abrt-cli again as root with report_uReport disabled, and got this: Analyzing coredump 'coredump' Cleaning cache... Cache cleaning has finished Coredump references 3 debuginfo files, 4 of them are not installed Initializing package manager Setting up repositories Errors during downloading metadata for repository 'rpmfusion-free-updates-debuginfo': - Status code: 404 for https://mirrors.rpmfusion.org/metalink?repo=free-fedora-updates-released-debug-33&arch=x86_64 (IP: 78.47.223.143) - Status code: 404 for https://mirrors.rpmfusion.org/metalink?repo=free-fedora-updates-released-debug-33&arch=x86_64 (IP: 158.69.60.128) Error: Failed to download metadata for repo 'rpmfusion-free-updates-debuginfo': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.rpmfusion.org/metalink?repo=free-fedora-updates-released-debug-33&arch=x86_64 (IP: 158.69.60.128) Ignoring repositories: rpmfusion-free-updates-debuginfo Looking for needed packages in repositories Can't find packages for 3 debuginfo files Packages to download: 1 Downloading 4.02Mb, installed size: 26.29Mb. Continue? [y/N] y Downloading (1 of 1) coreutils-debuginfo-8.32-12.fc33.x86_64.rpm: 14% Downloading (1 of 1) coreutils-debuginfo-8.32-12.fc33.x86_64.rpm: 65% Downloading (1 of 1) coreutils-debuginfo-8.32-12.fc33.x86_64.rpm: 100% Extracting cpio from /var/cache/dnf/fedora-debuginfo-85d473e83a9b48cd/packages/coreutils-debuginfo-8.32-12.fc33.x86_64.rpm Caching files from unpacked.cpio made from coreutils-debuginfo-8.32-12.fc33.x86_64.rpm Removing /var/tmp/abrt-tmp-debuginfo-2020-09-16-14:36:12.7076 Missing debuginfo file: /usr/lib/.build-id/c3/7cb90b77c79fc719798b066d78ef121285843e.debug Missing debuginfo file: /usr/lib/.build-id/26/02cd2de6dc672a5ec4378ace0b4a68ea5b13ea.debug Missing debuginfo file: /usr/lib/.build-id/e5/dff80def17abfde2ecdcfcc75208ab442b8d59.debug Generating backtrace Backtrace is generated and saved, 6 bytes double free or corruption (!prev) /usr/bin/abrt-action-analyze-ccpp-local: line 42: 7444 Aborted (core dumped) abrt-action-generate-backtrace ('analyze_CCpp' exited with 134)
Can we get retrace.fedoraproject.org to just resolve to something, anything, so that the fallback will work?
(In reply to Chris Murphy from comment #13) > Can we get retrace.fedoraproject.org to just resolve to something, anything, > so that the fallback will work? That's an interesting idea. Can you please edit your /etc/hosts and see if it helps you to make ABRT work?
The server is back online. It is pulling the data right now. I hope that it will be fully functional by tomorrow.
I'm able to get passed this bug now; and get a Report button, with an option to process locally. I do that, and then run into bug 1881745.
I can confirm ABRT no longer exits with "Could not resolve host: retrace.fedoraproject.org". Because https://bodhi.fedoraproject.org/updates/FEDORA-2020-444a3363f0 is already stable, I'm closing this.
For the record, I don't think Chris' idea would have worked. Again, the issue before the server came back up again was that the first 'event' in all the Fedora 'workflows' is report_uReport, and if that fails the 'workflow' just dies there. I think for report_uReport to work it not only needs to contact retrace.fedoraproject.org , but what it finds there does actually need to be a working retrace server that accepts its submission of a uReport. I do think abrt team could look at whether this event really *needs* to be 'fatal' in this way, or whether it would make more sense to just skip it if it doesn't work, and continue with the rest of the workflow.