Reporting is disabled because the generated backtrace has low informational value

[Chris Murphy]

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.


-- 
Chris Murphy

[Sam Varshavchik]

Chris Murphy writes:

>  Please try to install debuginfo manually using the command:
>  "debuginfo-install flatpak-1.4.1-1.fc30" and try again. 
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.

[Chris Murphy]

On Sun, Jun 23, 2019 at 8:35 PM Sam Varshavchik <mrsam(a)courier-mta.com&gt; wrote:
>  Chris Murphy writes:
>
>  > Please try to install debuginfo manually using the command:
>  > "debuginfo-install flatpak-1.4.1-1.fc30" and try again.
>
>  That's your key piece of info. You're missing the debuginfo package, without
>  it the backtrace has no info. 
I install it and get the same message, install it. Yet it's installed.

>  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. 
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.


-- 
Chris Murphy

[Chris Murphy]

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
https://bugzilla.redhat.com/show_bug.cgi?id=1723242
The apparent dup
https://bugzilla.redhat.com/show_bug.cgi?id=1697566

Not a good UX.


Chris Murphy

On Sun, Jun 23, 2019 at 9:34 PM, Sam Varshavchik 
<mrsam(a)courier-mta.com&gt; wrote:
>  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. 
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

On Mon, Jun 24, 2019 at 6:50 AM, mcatanzaro(a)gnome.org 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 
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] https://github.com/abrt/abrt/issues/1196

[Chris Murphy]

On Mon, Jun 24, 2019 at 5:57 AM <mcatanzaro(a)gnome.org&gt; wrote:
>  On Mon, Jun 24, 2019 at 6:50 AM, mcatanzaro(a)gnome.org 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
>
>  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. 

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

-- 
Chris Murphy