8:51 p.m.
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
9:34 p.m.
New subject: Reporting is disabled because the generated backtrace has low
informational value
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.
9:56 p.m.
On Sun, Jun 23, 2019 at 8:35 PM Sam Varshavchik <mrsam(a)courier-mta.com> 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
11:18 p.m.
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
6:50 a.m.
New subject: Reporting is disabled because the generated backtrace has low
informational value
On Sun, Jun 23, 2019 at 9:34 PM, Sam Varshavchik
<mrsam(a)courier-mta.com> 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
6:56 a.m.
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
10:03 a.m.
On Mon, Jun 24, 2019 at 5:57 AM <mcatanzaro(a)gnome.org> 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
1783
days inactive
1783
days old
6 comments
3 participants
participants (3)
-
Chris Murphy -
mcatanzaro＠gnome.org -
Sam Varshavchik