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 735598 - Gnome-maps freezes after right click
Gnome-maps freezes after right click
Status: RESOLVED FIXED
Product: clutter-gtk
Classification: Platform
Component: general
1.5.x
Other Linux
: Normal normal
: ---
Assigned To: clutter-gtk maintainer(s)
clutter-gtk maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-08-28 13:11 UTC by Petr Schindler
Modified: 2015-09-03 07:41 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Petr Schindler 2014-08-28 13:11:18 UTC
Description of problem:
When I right click on map the cursor is changed from hand to arrow and it looks like gnome-shell freezes. You can't switch applications, go to overview, click on anything, write, nothing works. Only mouse cursor is moving around.

Killing gnome-maps helps.

Version-Release number of selected component (if applicable):
gnome-maps-3.13.4-2.fc21.x86_64 (Fedora 21)

How reproducible:
100 % (tested on two computers

Steps to Reproduce:
1. open gnome-maps
2. right click on map

Actual results:
Everything seems to be freeze

Expected results:
I don't know :)
Comment 1 Elad Alfassa 2014-08-28 13:16:13 UTC
I can reproduce this too. Nothing interesting in the journal when this happens.
Comment 2 Jonas Danielsson 2014-08-28 13:18:03 UTC
I haven't seen it, will investigate further.

(Expected result is a context menu with possibility to reverse-geocode the location you click on :) )
Comment 3 Elad Alfassa 2014-08-28 17:18:05 UTC
Okay, here is some more data!

Backtrace on gnome-maps when the shell is stuck

syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
38		cmpq $-4095, %rax	/* Check %rax for error.  */
Missing separate debuginfos, use: debuginfo-install gnome-maps-3.13.4-2.fc21.x86_64
(gdb) bt
  • #0 syscall
    at ../sysdeps/unix/sysv/linux/x86_64/syscall.S line 38
  • #1 g_mutex_lock_slowpath
  • #2 clutter_gdk_handle_event
  • #3 gtk_clutter_embed_event
  • #4 _gtk_marshal_BOOLEAN__BOXEDv
  • #5 _g_closure_invoke_va
  • #6 g_signal_emit_valist
  • #7 g_signal_emit
  • #8 gtk_widget_event_internal
  • #9 synth_crossing
  • #10 _gtk_widget_synthesize_crossing
  • #11 synth_crossing_for_grab_notify.isra
  • #12 gtk_grab_notify_foreach
  • #13 gtk_grab_notify_foreach
  • #14 gtk_overlay_forall
  • #15 gtk_grab_notify_foreach
  • #16 gtk_window_forall
  • #17 gtk_grab_notify_foreach
  • #18 gtk_grab_notify
  • #19 gtk_menu_popup_for_device
  • #20 gtk_menu_popup
  • #21 ffi_call_unix64
  • #22 ffi_call
  • #23 0x0000003083c2efaa in
  • #24 0x0000003083c30458 in
  • #25 js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)
  • #26 Interpret(JSContext*, js::RunState&)
  • #27 js::RunScript(JSContext*, js::RunState&)
  • #28 js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)
  • #29 js_fun_apply(JSContext*, unsigned int, JS::Value*)
  • #30 js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)
  • #31 js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value*, JS::Value*)
  • #32 js::jit::DoCallFallback(JSContext*, js::jit::BaselineF---Type <return> to continue, or q <return> to quit--- rame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>)
  • #33 0x00007f4ccbf91aa2 in
  • #34 0x0000001839bc0000 in
  • #35 0x00007fff39bc0008 in
  • #36 0x000000000274eee0 in
  • #37 ()#38 0x00000030903b7300 in
  • #39 0x00007f4ccae35640 in
  • #40 0x00007f4ccbf95b4f in
  • #41 0x0000000000000502 in
  • #42 0x00007fff39bc00c8 in
  • #43 0x00000000029bd590 in
  • #44 0x0000000000000002 in
  • #45 0x00007fff39bc0050 in
  • #46 ()#47 0xffffffffffffffff in
  • #51 0x00000000029bd590 in
  • #52 0x00007f4cc809cf60 in
  • #53 0x0000000000000881 in
  • #54 ()#55 0xffffffffffffffff in


I also got a shell backtrace when it's stuck, but there's nothing interesting there.

Note that the shell is not completely frozen: windows behind the maps window update, and notifications are working too, but it can't handle pointer events - maps seems to be holding a grab on the mouse.
Comment 4 Jonas Danielsson 2014-08-28 18:59:20 UTC
Thanks!

I still can't reproduce this :(
What version of clutter are you guys running? It might be something there. Since the code for the context menu haven't changed in ages.
Comment 5 Elad Alfassa 2014-08-28 19:01:16 UTC
clutter-1.19.8-1.fc21.x86_64
clutter-gtk-1.5.4-1.fc21.x86_64
Comment 6 Jonas Danielsson 2014-08-28 19:09:36 UTC
Thanks!

With clutter-gtk 1.5.4 I coulds reproduce this.

But not with clutter-gtk master that had an revert:
commit a2a62570dd038a459326e3d56cb593af97e2f6f3
Author: Emmanuele Bassi <ebassi@gnome.org>
Date:   Thu Aug 28 15:44:44 2014 +0100

    Revert "Prefer the GDK windowing backend for Clutter"
    
    This reverts commit 0fc73a07770223964dbf41a20a4b0a8c3ef9a29c.
    
    I could have gotten away with this, if it wasn't for you meddling kids
    and your Wayland.

So it seems to be fixed, but I am shipping it over to clutter-gtk to make sure.

clutter-gtk-guys, is this known and/or fixed?
Comment 7 Elad Alfassa 2014-08-28 19:14:29 UTC
I liked the reference in this commit message :)

However, I should point out that it froze under X and I didn't bother to test on Wayland.
Comment 8 Jonas Danielsson 2014-08-28 19:28:47 UTC
Well, I run X as well. And it freezes on me when I check out the Release 1.5.4 commit.

But when I run master that only contains a version bump and the commit above, it does not.