← Back to team overview

openjdk team mailing list archive

[Bug 1510009] Re: Java 1.8.0_66 is extremely deadlock prone regarding AWT/GTK interaction

 

I noticed the hang in load_gtk when trying to run netbeans with
openjdk-7. For me disabling accessible like in https://bugs.debian.org
/cgi-bin/bugreport.cgi?bug=798131. The hand seems to be X11 threading
related based on other similar hangs reported in web.

My java backtrace:
"AWT-EventQueue-1" prio=10 tid=0x00007fc0dc163000 nid=0xb4e runnable [0x00007fc0d2b6f000]
   java.lang.Thread.State: RUNNABLE
	at sun.awt.UNIXToolkit.load_gtk(Native Method)
	at sun.awt.UNIXToolkit.loadGTK(UNIXToolkit.java:108)
	- locked <0x00000000d12681f0> (a java.lang.Object)
	at com.sun.java.swing.plaf.gtk.GTKLookAndFeel.initialize(GTKLookAndFeel.java:1452)
	at javax.swing.UIManager.setLookAndFeel(UIManager.java:535)
	at org.netbeans.swing.plaf.Startup.initialize(Unknown Source)
	at org.netbeans.swing.plaf.Startup.<init>(Unknown Source)
	at org.netbeans.swing.plaf.Startup.run(Unknown Source)
	at org.netbeans.core.CoreBridgeImpl$1$1.run(Unknown Source)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:745)
	at java.awt.EventQueue.access$300(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:706)
	at java.awt.EventQueue$3.run(EventQueue.java:704)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:77)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:715)
	at org.GNOME.Accessibility.AtkWrapper$5.dispatchEvent(AtkWrapper.java:697)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)


My native backtrace for same thread:
Thread 8 (Thread 0x7fc0d2b71700 (LWP 2894)):
#0  0x00007fc1399d98dd in poll () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fc1231dbbd2 in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x00007fc1231dd4df in ?? () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x00007fc1231dd5f1 in xcb_wait_for_reply () from /usr/lib/x86_64-linux-gnu/libxcb.so.1
#4  0x00007fc123d03a47 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007fc123cf99e6 in XQueryExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007fc123ced4f2 in XInitExtension () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007fc128269fdf in XextAddDisplay () from /usr/lib/x86_64-linux-gnu/libXext.so.6
#8  0x00007fc1238b6f63 in ?? () from /usr/lib/x86_64-linux-gnu/libXi.so.6
#9  0x00007fc1238b59a9 in XListInputDevices () from /usr/lib/x86_64-linux-gnu/libXi.so.6
#10 0x00007fc119ddbf99 in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#11 0x00007fc119db76a0 in gdk_display_open () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#12 0x00007fc119d8704f in gdk_display_open_default_libgtk_only ()
   from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0
#13 0x00007fc0d09d5882 in gtk_init_check () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#14 0x00007fc0d0ef6dbe in ?? () from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/libjavagtk.so
#15 0x00007fc0d0ef99db in Java_sun_awt_UNIXToolkit_load_1gtk ()
   from /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/libjavagtk.so
#16 0x00007fc12d0127f8 in ?? ()
#17 0x00007fc0fffffffe in ?? ()
#18 0x00007fc0d2b6f798 in ?? ()
#19 0x00000000b9ab2d88 in ?? ()
#20 0x00007fc0d2b6f7f0 in ?? ()
#21 0x00000000b9ab4718 in ?? ()
#22 0x0000000000000000 in ?? ()


Native backtrace looks a lot like situation where some other thread managed to steal the X11 reply deadlocking load_gtk call waiting for X11 reply.


After I once managed to start the netbeans with accessibility disabled the bug doesn't seem to reproduce any more with accessibility enabled.

I decided to try a bit more with accessibility enabled leading to more
hangs. But later on I managed to reproduce UI hang while native
backtraces show multiple threads calling g_main_context_iteration,
g_main_loop_run and Java_sun_awt_X11_XToolkit_waitForEvents. But glib
created threads in g_main_* calls seems not be the problem. Those
threads exists also when accessibility is disabled. That makes me think
that if race condition happens it isn't any more visible in native
backtraces when UI is hung.

I tested if XInitThreads gets called starting netbeans inside gdb with a break point:
handle SIGSEGV nostop noprint pass
b XInitThreads
r <Fill all neatbeans parameters from ps -f output>

I saw comments that java has rule that UI code is only allowed to run in
single thread. But I already have seen cases where UI code end ups
running from different threads. I have no idea why that happens in so
many applications suddenly.

I decided to test if simple calling XInitThreads would fix the issue with following gdb break point setup:
(gdb) b XOpenDisplay
Function "XOpenDisplay" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 4 (XOpenDisplay) pending.
(gdb) commands 4
Type commands for breakpoint(s) 4, one per line.
End with a line saying just "end".
>p XInitThreads()
>dis 4
>c
>end

The XOpenDisplay is called in main thread before any other thread
starts. But even with that modification Netbeans UI still managed to
hang. It is hard to try to guess where to look for issue any more than
that with multiple X connections involved and possibility that some
parts of code are using xcb. Maybe checking the accessibility wrapper
code would help.

-- 
You received this bug notification because you are a member of OpenJDK,
which is subscribed to openjdk-8 in Ubuntu.
https://bugs.launchpad.net/bugs/1510009

Title:
  Java 1.8.0_66 is extremely deadlock prone regarding AWT/GTK
  interaction

Status in openjdk-8 package in Ubuntu:
  Confirmed

Bug description:
  Since upgrading to Ubuntu 15.10 from Ubuntu 15.04, the various GUI
  applications that I run, including Netbeans and Minecraft have been
  suffering from dead/waitlocks which prevent them from operating
  properly. Since I have reproduced this issue these two completely
  different codebases, I am moving the bug further upstream.

  The original Netbeans bug report can be viewed here: https://netbeans.org/bugzilla/show_bug.cgi?id=256124
  Essentially, during routine interaction and calling of various AWT methods, somewhere between 8u45 (15.04) and 8u66 (15.10), something broke causing the application to hang intermittently when these methods are called.

  Some sample jstack traces are attached, the issue should be fairly
  obvious to spot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1510009/+subscriptions


References