JDK-7123957 : Switch of Gnome theme ends up deadlocked in GTKEngine.native_switch_theme (regression in Java 7)
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u31,7,7u6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux,linux_ubuntu
  • CPU: generic,x86
  • Submitted: 2011-12-22
  • Updated: 2020-04-29
  • Resolved: 2012-06-12
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 JDK 8
7u6Fixed 8 b43Fixed
Related Reports
Duplicate :  
JDK-7166433 - Hang during theme change on gnome 3
Duplicate :  
JDK-7053002 - cte-7b145-java console can't pop up
Relates :  
JDK-8244088 - [Regression] Switch of Gnome theme ends up in deadlocked UI
Description
A regression in Java 7 which freezes EDT of the application inside
com.sun.java.swing.plaf.gtk.GTKEngine.native_switch_theme(Native Method)
after Gnome theme change.

The problem is reproducible with all of Java 7, 7u1, 7u2. Tested on Ubuntu 10.10 but most probably reproducible on all Gnome installations.

With Java 6u30 the problem is not manifested. The application correctly adapts its GTK L&F to the new theme.

Related netbeans bug:
http://netbeans.org/bugzilla/show_bug.cgi?id=206271
Comments
Verified!
23-05-2013
SUGGESTED FIX Fixed - http://hg.openjdk.java.net/jdk8/awt/jdk/rev/5880da7a3628
05-06-2012
EVALUATION Here's the native stack: Thread 2 (Thread 0xa0c8bb70 (LWP 28253)): #0 0x00fc2422 in __kernel_vsyscall () #1 0x00db7af9 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x00db3158 in _L_lock_979 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x00db30c9 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x06f74f32 in g_mutex_lock (mutex=0x9781d80) at gthread-posix.c:208 #5 0x00b85096 in gdk_threads_impl_lock () at /build/buildd/gtk+2.0-2.20.1/gdk/gdk.c:430 #6 0x00bc2937 in gdk_event_prepare (source=0x97a3058, timeout=0xa0c8a67c) at /build/buildd/gtk+2.0-2.20.1/gdk/x11/gdkevents-x11.c:2326 #7 0x06f357b8 in g_main_context_prepare (context=0x97a30c0, priority=0xa0c8a6dc) at gmain.c:2813 #8 0x06f35933 in g_main_context_iterate (context=0x97a30c0, block=<value optimized out>, dispatch=1, self=0x9831320) at gmain.c:3103 #9 0x06f35b23 in g_main_context_iteration (context=0x97a30c0, may_block=0) at gmain.c:3184 #10 0x003a7d46 in flush_gtk_event_loop () from /export/hailer/ws/deploy/8/build/linux-i586/j2re-image/lib/i386/libawt_xawt.so #11 0x003a93ff in Java_com_sun_java_swing_plaf_gtk_GTKEngine_native_1switch_1theme () from /export/hailer/ws/deploy/8/build/linux-i586/j2re-image/lib/i386/libawt_xawt.so Seems like the cause of the issue is that we wrap g_main_context_iteration with gdk_threads_enter/gdk_threads_exit while g_main_context_iteration takes care of locks. The issue is a regression of the changes for 6913179: http://hg.openjdk.java.net/jdk7/awt/jdk/diff/5eccce06fed5/src/solaris/native/sun/awt/swing_GTKEngine.c (flush_gtk_event_loop calls g_main_context_iteration)
01-06-2012