Bug 1120863 - Epiphany crashes are reported as BBC iPlayer crashes
Summary: Epiphany crashes are reported as BBC iPlayer crashes
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-abrt
Version: 21
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jakub Filak
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:2a79d2143b4938d0b58b78721b8...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-17 21:37 UTC by Michael Catanzaro
Modified: 2016-12-01 00:49 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-02 03:16:33 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Screenshot of issue (41.87 KB, image/png)
2014-07-17 22:05 UTC, Michael Catanzaro
no flags Details
cmdline (40 bytes, text/plain)
2014-07-18 21:31 UTC, Michael Catanzaro
no flags Details
executable (17 bytes, text/plain)
2014-07-18 21:31 UTC, Michael Catanzaro
no flags Details
component (8 bytes, text/plain)
2014-07-18 21:32 UTC, Michael Catanzaro
no flags Details
epiphany.desktop (15.86 KB, text/plain)
2014-07-18 21:32 UTC, Michael Catanzaro
no flags Details
bogus epiphany.desktop (545 bytes, text/plain)
2014-07-18 21:33 UTC, Michael Catanzaro
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github abrt gnome-abrt issues 106 0 None None None Never

Description Michael Catanzaro 2014-07-17 21:37:20 UTC
Description of problem:
Whenever Epiphany crashes, it appears in gnome-abrt as "BBC iPlayer" which is pretty insane. It seems to be one of the default desktop files installed by Epiphany (into ~/.local/share/applications) that launches the normal Epiphany binary in application mode:

Note that I've never used this web app (it even has NoDisplay=true), so it's really confusing.

[Desktop Entry]
Name=BBC iPlayer
Comment=Catch up on BBC TV and Radio programmes, or watch/listen live
Exec=epiphany --application-mode --profile="/home/mcatanzaro/.config/epiphany/app-epiphany-bbciplayer-23ce23f45976e71a9dbbd3e728ade6acf6f2067d" http://www.bbc.co.uk/iplayer/bigscreen
StartupNotify=true
Terminal=false
NoDisplay=true
Type=Application
Icon=/home/mcatanzaro/.config/epiphany/app-epiphany-bbciplayer-23ce23f45976e71a9dbbd3e728ade6acf6f2067d/app-icon.png
StartupWMClass=epiphany-bbciplayer-23ce23f45976e71a9dbbd3e728ade6acf6f2067d

Version-Release number of selected component:
gnome-abrt-0.3.7

Additional info:
reporter:       libreport-2.2.2
kernel:         3.15.4-200.fc20.x86_64
type:           libreport

Comment 1 Michael Catanzaro 2014-07-17 22:05:10 UTC
Created attachment 918854 [details]
Screenshot of issue

Comment 2 Jakub Filak 2014-07-18 13:47:37 UTC
Hello, I installed Epiphany and my ~/.local/share/applications was empty. So, I opened http://www.bbc.co.uk/iplayer/bigscreen, clicked the gear -> "Save As Web Application" and it created a desktop entry like yours. Unfortunately, my desktop entry for BBC does not have 'NoDisplay=true', so I have to find a different way how to identify these desktop entries. Perhaps I can try to limit searched desktop files to system only, but GIO do not offer such an option.

If I run epiphany ("Web" application) and kill it with SEGV, ABRT GUI displays "Web" in the problems list. If I run BBC application ("BBC iPlayer" application) and kill it with SEGV, ABRT GUI displays "BBC iPlayer" in the problems list. I am not an UX expert so I need your help. What do you think about it, what would be the best for users? (they see "BBC iPlayer" in Task bar, they clicked "BBC iPlayer" in Applications)

I can filter out "NoDisplay=true" desktop items, but what else should I filter out?

Comment 3 Michael Catanzaro 2014-07-18 16:32:27 UTC
(In reply to Jakub Filak from comment #2)
> Hello, I installed Epiphany and my ~/.local/share/applications was empty.
> So, I opened http://www.bbc.co.uk/iplayer/bigscreen, clicked the gear ->
> "Save As Web Application" and it created a desktop entry like yours.
> Unfortunately, my desktop entry for BBC does not have 'NoDisplay=true', so I
> have to find a different way how to identify these desktop entries.

Normal web apps would not have NoDisplay set. I'm frankly not sure why Epiphany created these for me. Filtering apps with NoDisplay might be a good place to start, though, but I'm not sure it's really necessary.

> Perhaps
> I can try to limit searched desktop files to system only, but GIO do not
> offer such an option.

Hm... would that conflict with ABRT's hidden feature for processing unpackaged files?

> If I run epiphany ("Web" application) and kill it with SEGV, ABRT GUI
> displays "Web" in the problems list. If I run BBC application ("BBC iPlayer"
> application) and kill it with SEGV, ABRT GUI displays "BBC iPlayer" in the
> problems list. I am not an UX expert so I need your help. What do you think
> about it, what would be the best for users? (they see "BBC iPlayer" in Task
> bar, they clicked "BBC iPlayer" in Applications)

Hm, I think it would be better to always show Epiphany rather than the web app name, since Epiphany and not the web app is not responsible for the crash... but either way, this is not really a big deal. What's more important is that when Epiphany is not running as a web app, the crash should not be reported as if it was coming from a web app.

Probably the thing to do here would be to be more strict with the Exec line when looking for a matching desktop file. I think you're currently discarding everything after the executable name in the desktop file when deciding which desktop file matches the crash, right? That's probably a good fallback, but I would first prefer a desktop file that best matches the actual command line of the crashing program. Specifically, I would expect a desktop file with Exec=epiphany to be matched rather than one with Exec=epiphany --whatever

Comment 4 Jakub Filak 2014-07-18 19:19:18 UTC
(In reply to Michael Catanzaro from comment #3)
> (In reply to Jakub Filak from comment #2)
> > Hello, I installed Epiphany and my ~/.local/share/applications was empty.
> > So, I opened http://www.bbc.co.uk/iplayer/bigscreen, clicked the gear ->
> > "Save As Web Application" and it created a desktop entry like yours.
> > Unfortunately, my desktop entry for BBC does not have 'NoDisplay=true', so I
> > have to find a different way how to identify these desktop entries.
> 
> Normal web apps would not have NoDisplay set. I'm frankly not sure why
> Epiphany created these for me. Filtering apps with NoDisplay might be a good
> place to start, though, but I'm not sure it's really necessary.
> 
> > Perhaps
> > I can try to limit searched desktop files to system only, but GIO do not
> > offer such an option.
> 
> Hm... would that conflict with ABRT's hidden feature for processing
> unpackaged files?
> 

No. The detection of unpackaged files has nothing common with displaying icons and human readable names in the GUI. ABRT uses 'rpm -qf $absolute_path_to_crashed_executable' to detect unpackaged executables.

> > If I run epiphany ("Web" application) and kill it with SEGV, ABRT GUI
> > displays "Web" in the problems list. If I run BBC application ("BBC iPlayer"
> > application) and kill it with SEGV, ABRT GUI displays "BBC iPlayer" in the
> > problems list. I am not an UX expert so I need your help. What do you think
> > about it, what would be the best for users? (they see "BBC iPlayer" in Task
> > bar, they clicked "BBC iPlayer" in Applications)
> 

> What's more
> important is that when Epiphany is not running as a web app, the crash
> should not be reported as if it was coming from a web app.

Sure, the crash is always reported as a bug in Epiphany.

> 
> Probably the thing to do here would be to be more strict with the Exec line
> when looking for a matching desktop file. I think you're currently
> discarding everything after the executable name in the desktop file when
> deciding which desktop file matches the crash, right?

No. The executable comparison is the last possibility to find the corresponding desktop file [1].

> That's probably a good fallback,

Sure.

> but I would first prefer a desktop file that best matches the
> actual command line of the crashing program.

Me as well.

> Specifically, I would expect a
> desktop file with Exec=epiphany to be matched rather than one with
> Exec=epiphany --whatever

Yes, as I wrote in comment #2, it works on my F20 box.

Could you please attach Epiphany's desktop file and 'cmdline', 'executable' and 'component' files from the dump directory?


1: https://github.com/abrt/gnome-abrt/blob/master/src/gnome_abrt/application.py#L119

Comment 5 Michael Catanzaro 2014-07-18 21:31:42 UTC
Created attachment 919173 [details]
cmdline

Comment 6 Michael Catanzaro 2014-07-18 21:31:54 UTC
Created attachment 919174 [details]
executable

Comment 7 Michael Catanzaro 2014-07-18 21:32:10 UTC
Created attachment 919175 [details]
component

Comment 8 Michael Catanzaro 2014-07-18 21:32:54 UTC
Created attachment 919176 [details]
epiphany.desktop

Here's the real epiphany.desktop

Comment 9 Michael Catanzaro 2014-07-18 21:33:43 UTC
Created attachment 919177 [details]
bogus epiphany.desktop

Here's the epiphany.desktop that abrt seems to be using.

Comment 10 Michael Catanzaro 2014-07-18 21:40:13 UTC
(In reply to Jakub Filak from comment #4)
> > What's more
> > important is that when Epiphany is not running as a web app, the crash
> > should not be reported as if it was coming from a web app.
> 
> Sure, the crash is always reported as a bug in Epiphany.

What I meant to say is, the crash should not be presented to the user as a bug in a web app if Epiphany is not running in web app mode. I don't care too much what happens if Epiphany is actually running as a web app, whether the crash is presented as an Epiphany crash or a crash of that particular web app (as long as ABRT does not present it as a different web app).

Try installing that BBC desktop file in ~/.local/share/applications, then I think you'll be able to reproduce this if you send SIGSEGV to Epiphany (not running as a web app).

Comment 11 Jakub Filak 2014-07-21 15:27:17 UTC
Thank you for the files Michael! I found a bug in usage of os.path.basename() but it is not the root cause of your issue. The root cause of your is that Epiphany's Exec key is "epiphany %U", therefore the GUI rejects its desktop file for all variants of command line ('epiphany', 'epiphany http://bugzilla.redhat.com/', etc.), because the GUI do not understand the Exec key format yet, and fallbacks to the search by executable where both Epiphany's file and the bogus file have the same value "epiphany". Unfortunately, the bogus file is accessed first.

Comment 12 Jakub Filak 2014-07-22 11:00:47 UTC
Michael, could you please install the following scratch build, retest and report the results here?

http://koji.fedoraproject.org/koji/taskinfo?taskID=7176548

Comment 13 Michael Catanzaro 2014-07-22 13:11:49 UTC
Jakub, I think that build fixes it, thanks!

Comment 14 Jakub Filak 2014-07-22 13:17:27 UTC
(In reply to Michael Catanzaro from comment #13)

Thank you for your cooperation!

Upstream commit https://github.com/abrt/gnome-abrt/commit/dfa92d13f6843f2fba71f81e7b001f008951b686 fixes this bug.

Comment 15 Fedora End Of Life 2015-05-29 12:23:50 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 16 Fedora End Of Life 2015-11-04 11:42:39 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 17 Fedora End Of Life 2015-12-02 03:16:35 UTC
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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