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 632501 - GNOME Shell fails to start
GNOME Shell fails to start
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal critical
: ---
Assigned To: Colin Walters
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2010-10-18 20:22 UTC by Giovanni Campagna
Modified: 2011-03-22 02:43 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Ensure ShellApp->priv->running_state is not NULL (1.17 KB, patch)
2010-10-18 20:22 UTC, Giovanni Campagna 		none Details | Review
Transition the ShellApp state when ready. (1.32 KB, patch)
2010-11-07 19:53 UTC, Giovanni Campagna 		committed Details | Review

Description Giovanni Campagna 2010-10-18 20:22:02 UTC 
Created attachment 172643 [details] [review]
Ensure ShellApp->priv->running_state is not NULL

Current gnome-shell master cannot be started, it reproducibly segfaults at startup.
I attached a possible fix/workaround, though the bug is that for some weird reason ShellApp emits a "notify" signal for state while notify is frozen (as ->priv->running_state is NULL).
Comment 1 Owen Taylor 2010-10-19 19:05:19 UTC 
Not happening for me - probably something different about my set of running applications?

I'm a little skeptical that a GObject:: notify signal will ever be emitted on an object between g_object_freeze() notify and g_object_thaw_notify().

Can you provide a backtrace of the crash?
Comment 2 Giovanni Campagna 2010-10-19 20:13:54 UTC 
Actually, no.
All at once it decided to work again unpatched.
I tried reproducing the exact sequence of windows that made it crash reproducibly yesterday, but it still worked perfectly, so I think this can be closed.
Comment 3 Giovanni Campagna 2010-10-20 18:37:38 UTC 
Happened again, so reopening, but this time I am able to provide a stack trace.
As you can see, shell_app_state_transition is calling g_signal_emit.

+ Trace 224249

  • #0 shell_app_compare
    at shell-app.c line 633
  • #1 g_slist_sort_merge
    at gslist.c line 974
  • #2 g_slist_sort_real
    at gslist.c line 1016
  • #3 g_slist_sort_real
    at gslist.c line 1016
  • #4 shell_window_tracker_get_running_apps
    at shell-window-tracker.c line 800
  • #5 ffi_call_unix64
    at src/x86/unix64.S line 75
  • #6 ffi_call
    at src/x86/ffi64.c line 484
  • #7 gjs_invoke_c_function
    at gi/function.c line 580
  • #8 js_Invoke
    at jsinterp.cpp line 1360
  • #9 js_Interpret
    at jsops.cpp line 2240
  • #10 js_Invoke
    at jsinterp.cpp line 1368
  • #11 js_fun_apply
    at jsfun.cpp line 2046
  • #12 js_Interpret
    at jsops.cpp line 2208
  • #13 js_Invoke
    at jsinterp.cpp line 1368
  • #14 js_InternalInvoke
    at jsinterp.cpp line 1423
  • #15 JS_CallFunctionValue
    at jsapi.cpp line 5114
  • #16 gjs_call_function_value
    at gjs/jsapi-util.c line 1120
  • #17 gjs_closure_invoke
    at gi/closure.c line 267
  • #18 closure_marshal
    at gi/value.c line 126
  • #19 g_closure_invoke
    at gclosure.c line 766
  • #20 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #21 g_signal_emit_valist
    at gsignal.c line 2983
  • #22 g_signal_emit
    at gsignal.c line 3040
  • #23 shell_app_state_transition
    at shell-app.c line 684
  • #24 _shell_app_add_window
    at shell-app.c line 743
  • #25 track_window
    at shell-window-tracker.c line 516
  • #26 g_closure_invoke
    at gclosure.c line 766
  • #27 signal_emit_unlocked_R
    at gsignal.c line 3252
  • #28 g_signal_emit_valist
    at gsignal.c line 2983
  • #29 g_signal_emit
    at gsignal.c line 3040
  • #30 meta_workspace_add_window
    at core/workspace.c line 350
  • #31 meta_window_new_with_attrs
    at core/window.c line 1067
  • #32 meta_window_new
    at core/window.c line 494
  • #33 event_callback
    at core/display.c line 2280
  • #34 filter_func
    at ui/ui.c line 87
  • #35 gdk_event_apply_filters
    at gdkeventsource.c line 72
  • #36 gdk_event_source_translate_event
    at gdkeventsource.c line 145
  • #37 _gdk_events_queue
    at gdkeventsource.c line 276
  • #38 gdk_display_get_event
    at gdkdisplay.c line 384
  • #39 gdk_event_source_dispatch
    at gdkeventsource.c line 298
  • #40 g_main_dispatch
    at gmain.c line 2149
  • #41 g_main_context_dispatch
    at gmain.c line 2702
  • #42 g_main_context_iterate
    at gmain.c line 2780
  • #43 g_main_loop_run
    at gmain.c line 2988
  • #44 main
    at core/main.c line 725 






Comment 4


Giovanni Campagna





          2010-11-07 19:53:26 UTC
        



Created attachment 174017 [details] [review]
Transition the ShellApp state when ready.

shell_app_state_transition emits a signal, so invoke it only when
ready, or signal handlers will see an object which is in an invalid
state.






Comment 5


Colin Walters





          2011-03-21 19:17:14 UTC
        



Review of attachment 174017 [details] [review]:

::: src/shell-app.c
@@ +753,3 @@
 
+  if (app->state != SHELL_APP_STATE_STARTING && app->state != SHELL_APP_STATE_RUNNING)
+    shell_app_state_transition (app, SHELL_APP_STATE_RUNNING);

You don't need the && app->state != SHELL_APP_STATE_RUNNING, shell_app_state_transition() does that for you.

Otherwise looks good, thanks!






Comment 6


Owen Taylor





          2011-03-22 02:43:00 UTC
        



Removed check for app->state != SHELL_APP_STATE_RUNNING as per Colin's comment and pushed.

Thanks for the patch!

Attachment 174017 [details] pushed as 54e3a54 - Transition the ShellApp state when ready.