After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 674799 - Crash when clicking on "<X> is ready" for a window-backed app
Crash when clicking on "<X> is ready" for a window-backed app
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 710050 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-04-25 14:59 UTC by Owen Taylor
Modified: 2015-10-12 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Don't crash on accesses to stale window-backed apps (3.15 KB, patch)
2015-10-08 03:16 UTC, Owen Taylor
committed Details | Review

Description Owen Taylor 2012-04-25 14:59:35 UTC
See https://bugzilla.redhat.com/show_bug.cgi?id=768136

If you have a window-backed (unassociated app) that shows an "X is ready" notification, then the app goes away before the user clicks on the notification, then the assertion:

static MetaWindow *
window_backed_app_get_window (ShellApp     *app)
{
  g_assert (app->entry == NULL);
>>>>>  g_assert (app->running_state);
  g_assert (app->running_state->windows);
  return app->running_state->windows->data;
}

fails - the 'app' object has been kept around by windowAttentionHandler.js:Source after the app stops running.

I'm not sure if in the bug report the window went away because:
 
 - It's a splash screen that closed
 - It was a generic LibreOffice window that changed it's WM_CLASS to a specific LibreOffice app and became associated

Both are potentially possible? - for the second case you probably need to delay/repeat the call to tracker.get_window_app(window) so that the right app is dealt with at click time.
Comment 1 Owen Taylor 2015-10-08 03:01:47 UTC
*** Bug 710050 has been marked as a duplicate of this bug. ***
Comment 2 Owen Taylor 2015-10-08 03:16:19 UTC
Created attachment 312877 [details] [review]
Don't crash on accesses to stale window-backed apps

The JS code could still be holding on to a reference to a window-backed app
after all windows have vanished. (For example, the dash queues an idle to
refetch apps and display them.) Avoid dying with an error message if we
attempt to activate or otherwise manipulate such a window.
Comment 3 Owen Taylor 2015-10-08 03:21:17 UTC
What I attached is a generic "don't crash" fix. It doesn't attempt to fix the "<X> is ready" popups - but the "<X> is ready popups" aren't only way that this crash could be triggered - it could be triggered, for example, by clicking on a dash icon at the moment that a window backed app went away, before the dash had a chance to redisplay.
Comment 4 Jasper St. Pierre (not reading bugmail) 2015-10-08 15:58:00 UTC
Review of attachment 312877 [details] [review]:

I'm on the fence about this. On one hand, this weakens our invariants, which I'm not a giant fan of. On the other, I understand the utility here. Let's go with it.
Comment 5 Owen Taylor 2015-10-12 14:16:11 UTC
I'm going to mark this as FIXED, because I couldn't figure out how to get the
original case of "<X> is ready" for a window-backed application; and if it's
so hard reproduce I can accept a minor misbehavior with it.

Attachment 312877 [details] pushed as db297e7 - Don't crash on accesses to stale window-backed apps