DevHeads.net

Reporting is disabled because the generated backtrace has low informational value

I've got a 100% reproducible crash ([chris@flap ~]$ flatpak install
--from com.slack.Slack.flatpakref from flathub.org) and every time
abrt+retrace server puke on it as having low informational value.

That strikes me as either a bug in abrt or the package or libraries it
depends on but I can't figure out which.

$ sudo abrt-cli list
[sudo] password for chris:
Sorry, try again.
[sudo] password for chris:
id 645e5e13c63a70214dd45fe5514dae06d9ad395c
reason: flatpak killed by SIGSEGV
time: Sun 23 Jun 2019 07:28:19 PM MDT
cmdline: flatpak install --from com.slack.Slack.flatpakref
package: flatpak-1.4.1-1.fc30
uid: 1000 (chris)
count: 1
Directory: /var/spool/abrt/ccpp-2019-06-23-19:28:19.332559-6190
[chris@flap ~]$ sudo abrt-cli report
/var/spool/abrt/ccpp-2019-06-23-19:28:19.332559-6190
('report_uReport' completed successfully)
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). [y/N/f/e] y
Querying server settings
Preparing an archive to upload
Uploading 6.4 MiB
Upload successful
Retrace job started
Analyzing crash data
..............................
Preparing environment for backtrace generation
.........
Generating backtrace
Cleaning environment after backtrace generation
Saving crash statistics
Looking for similar problems in bugzilla
Reporting is disabled because the generated backtrace has low
informational value.
Please try to install debuginfo manually using the command:
"debuginfo-install flatpak-1.4.1-1.fc30" and try again.

Comments

Re: Reporting is disabled because the generated backtrace has lo

By Sam Varshavchik at 06/23/2019 - 21:34

Chris Murphy writes:

That's your key piece of info. You're missing the debuginfo package, without
it the backtrace has no info.

With a native, directly-installed RPM, the debug repo gets automatically
enabled, and the debuginfo packages gets automatically fetched and
installed. I guess with flatpacks, this is not automatic. Don't know much
about flatpaks, but this is what you need to figure out how to make it
happen.

Re: Reporting is disabled because the generated backtrace has lo

By Michael Catanzaro at 06/24/2019 - 06:50

On Sun, Jun 23, 2019 at 9:34 PM, Sam Varshavchik
<mrsam@courier-mta.com> wrote:
That's not right. The backtrace was processed on the retrace server, so
installing debuginfo locally should not be required.

I think it's a longstanding ABRT bug.

Michael

Re: Reporting is disabled because the generated backtrace has lo

By Michael Catanzaro at 06/24/2019 - 06:56

On Mon, Jun 24, 2019 at 6:50 AM, <a href="mailto: ... at gnome dot org"> ... at gnome dot org</a> wrote:
Oh, I forgot what I was actually planning to write about when I decided
to send a mail. ABRT doesn't support reporting crashes from flatpak
apps. It's a feature we requested a while ago [1]. In the meantime, if
a flatpak app crashes, you'll have to generate a backtrace manually
using the flatpak-coredumpctl command:

$ flatpak-coredumpctl org.gnome.Epiphany.Devel//master

So that's easy, but the backtrace will be useless unless you have debug
symbols installed for both the runtime and the application. I can never
remember how to do that and there doesn't exist documentation anywhere
that I can see. ABRT will need to learn how to do all of this.

None of this is relevant to Chris's crash, because he's not reporting
that a flatpak application is crashing. He's reporting that flatpak
itself is crashing. ABRT should already be able to handle this like it
does any other bug, and it's surely an ABRT bug for it to have failed
here.

[1] <a href="https://github.com/abrt/abrt/issues/1196" title="https://github.com/abrt/abrt/issues/1196">https://github.com/abrt/abrt/issues/1196</a>

Re: Reporting is disabled because the generated backtrace has lo

By Chris Murphy at 06/24/2019 - 10:03

On Mon, Jun 24, 2019 at 5:57 AM < ... at gnome dot org> wrote:

I'm gonna add all of this to the recent abrt solicitation for features
and complaints.

Re: Reporting is disabled because the generated backtrace has lo

By Chris Murphy at 06/23/2019 - 21:56

On Sun, Jun 23, 2019 at 8:35 PM Sam Varshavchik <mrsam@courier-mta.com> wrote:
I install it and get the same message, install it. Yet it's installed.

flatpak itself is an RPM, I'm not even able to use any flatpaks yet
because flatpak itself keeps crashing on a clean installed Fedora 30
system.

Re: Reporting is disabled because the generated backtrace has lo

By Chris Murphy at 06/23/2019 - 23:18

OK so after spending three hours downloading and installing debug
symbols, because the generation can't tell me all the symbols needed
in one whack, I get to learn that this is a dup of another bug. I'm
perplexed why a locally generated back trace figures this out, but the
retrace server gives up?

It's also an old bug from April. I wasn't encounting this problem
until I did a clean install of Fedora 30 on my laptop today.

Mine
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1723242" title="https://bugzilla.redhat.com/show_bug.cgi?id=1723242">https://bugzilla.redhat.com/show_bug.cgi?id=1723242</a>
The apparent dup
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1697566" title="https://bugzilla.redhat.com/show_bug.cgi?id=1697566">https://bugzilla.redhat.com/show_bug.cgi?id=1697566</a>

Not a good UX.

Chris Murphy