Bug 735598 – Gnome-maps freezes after right click

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


Summary:	Gnome-maps freezes after right click


Status:	RESOLVED FIXED

Product:	clutter-gtk
Classification:	Platform
Component:	general
Version:	1.5.x
Hardware:	Other Linux

Importance:	Normal normal
Target Milestone:	---
Assigned To:	clutter-gtk maintainer(s)
QA Contact:	clutter-gtk maintainer(s)

URL:
Whiteboard:

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

+ Trace 234018

#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.