Bug 629277 – Hanging because do_syntheszie_crossing_event is called without a lock

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 629277 - Hanging because do_syntheszie_crossing_event is called without a lock


Summary:	Hanging because do_syntheszie_crossing_event is called without a lock


Status:	RESOLVED FIXED

Product:	gtk+
Classification:	Platform
Component:	Backend: X11
Version:	2.18.x
Hardware:	Other Linux

Importance:	Normal major
Target Milestone:	---
Assigned To:	gtk-bugs
QA Contact:	gtk-bugs

URL:
Whiteboard:

Depends on:
Blocks:

Reported:	2010-09-10 14:06 UTC by Yehouda
Modified:	2010-09-12 14:57 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Yehouda 2010-09-10 14:06:43 UTC

do_synthesize_crossing_event is scheduled as idle using g_idle_add_full inside _gdk_synthesize_crossing_event_for_geometry_change. This causes do_synthesize_crossing_event to be called without a lock, and it can mess up things. 

backtrace below.


The result is a mix-up of h erequest count, and the end result is that _XReply hang waiting for a request. 

We actually saw it in 2.20, but the wrong code is already in 2.18.

++++++++++++++++   GIT change

http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-20&id=278e5bd1707601a75273737b49ecdbcd452ff42e




author	Alexander Larsson <alexl@redhat.com>	2009-06-11 19:49:17 (GMT)
committer	Alexander Larsson <alexl@redhat.com>	2009-06-11 19:49:17 (GMT)
commit	278e5bd1707601a75273737b49ecdbcd452ff42e (patch) (side-by-side diff)
tree	05d714929e0a131e80fe101554d4a2640786a814
parent	4987ca9235c672e34adab84aea3886b0a0e2f060 (diff)
Send crossing event due to geometry change in idle
Doing this directly had some issues with picking going recursive in clutter-gtk. Furthermore, doing it in an idle means we can coalesce multiple calls (which is common due to widget changes) in the same toplevel to just one call.
Diffstat


++++++++++++++++++  backtrace

+ Trace 223632

Thread 4 (Thread 0xb65ffb70 (LWP 19533))

#0 XDefineCursor
at DefCursor.c line 43
#1 gdk_window_x11_set_cursor
at gdkwindow-x11.c line 2744
#2 update_cursor
at gdkwindow.c line 8969
#3 _gdk_display_set_window_under_pointer
at gdkwindow.c line 9715
#4 do_synthesize_crossing_event
at gdkwindow.c line 9872
#5 g_idle_dispatch
at gmain.c line 4065
#6 g_main_dispatch
at gmain.c line 1960
#7 IA__g_main_context_dispatch
at gmain.c line 2513
#8 g_main_context_iterate
at gmain.c line 2591
#9 IA__g_main_loop_run
at gmain.c line 2799
#10 ??

Comment 1 Matthias Clasen 2010-09-11 02:34:00 UTC

commit 08dd02fe255487f5c7953de9b2c8b63c2e937989
Author: Matthias Clasen <mclasen@redhat.com>
Date:   Fri Sep 10 22:28:55 2010 -0400

    Don't use g_idle_add to schedule idles in GDK
    
    We need to use gdk_threads_add_idle, in order to keep GDK code
    under the GDK lock.
    
    Bug 629277

Comment 2 Yehouda 2010-09-12 14:57:31 UTC

Can this be fixed in the released versions?

It is a serious bug, because the process just hang, and there is no obvious way around it.