Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1878317 - Can't report a crash (even with local processing) due to "Could not resolve host: retrace.fedoraproject.org"
Summary: Can't report a crash (even with local processing) due to "Could not resolve h...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: abrt
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: abrt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: F33BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2020-09-11 23:02 UTC by Chris Murphy
Modified: 2020-10-04 17:32 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-23 07:36:33 UTC
Type: Bug


Attachments (Terms of Use)
screenshot (210.60 KB, image/png)
2020-09-11 23:02 UTC, Chris Murphy
no flags Details

Description Chris Murphy 2020-09-11 23:02:59 UTC
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:

Comment 1 Chris Murphy 2020-09-11 23:03:39 UTC
Might be a dup of bug 1873029. Filing a new bug because the message in gnome-abrt is different.

Comment 2 Chris Murphy 2020-09-11 23:19:39 UTC
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.

Comment 3 Fedora Blocker Bugs Application 2020-09-11 23:22:35 UTC
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

Comment 4 Chris Murphy 2020-09-11 23:25:01 UTC
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

Comment 5 Michael Catanzaro 2020-09-12 13:13:46 UTC
(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.

Comment 6 Geoffrey Marr 2020-09-14 20:18:00 UTC
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

Comment 7 Kamil Páral 2020-09-15 07:08:56 UTC
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.

Comment 8 Kamil Páral 2020-09-15 07:13:55 UTC
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].

Comment 9 Adam Williamson 2020-09-15 15:24:09 UTC
For the record I agree with Kamil's reasoning from #c7 here.

Comment 10 Adam Williamson 2020-09-16 00:04:36 UTC
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...

Comment 11 Adam Williamson 2020-09-16 00:05:55 UTC
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.

Comment 12 Adam Williamson 2020-09-17 21:34:50 UTC
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)

Comment 13 Chris Murphy 2020-09-22 16:32:27 UTC
Can we get retrace.fedoraproject.org to just resolve to something, anything, so that the fallback will work?

Comment 14 Kamil Páral 2020-09-22 19:28:06 UTC
(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?

Comment 15 Miroslav Suchý 2020-09-22 19:41:05 UTC
The server is back online. It is pulling the data right now. I hope that it will be fully functional by tomorrow.

Comment 16 Chris Murphy 2020-09-23 02:01:49 UTC
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.

Comment 17 Kamil Páral 2020-09-23 07:36:33 UTC
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.

Comment 18 Adam Williamson 2020-10-04 17:32:42 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.