Community
Participate
Working Groups
SWT and AWT/swing (if the GTK L&F is used) are both making GTK function calls. They both have locks to protect there own threads from accessing GTK concurrently. AWT uses the GTK lock (gdk_threads_enter()/gdk_threads_leave()). SWT uses its own locking, because the GTK lock is not reentrant. In order to make both toolkits synchronize access to GTK/X, they need to use a single lock. The obvious choice is to use the GTK lock, but this has been proven to be impossible because that lock is not reentrant. It is fairly easy to have a deadlock even in a single threaded program. See bug#280649 and bug#341085 for examples. One possible solution is to make the GTK lock reentrant by calling gdk_threads_set_locking_functions(). This has to be done by both toolkits before the call to gdk_threads_init().
Hi Artem, is the solution I mentioned above reasonable?
Solving this bug would also help bug#139468.
I haven't looked through all the GTK calls in AWT/Swing, but I suspect we don't need GTK lock reentrancy. As far as I understand your suggestion, the changes are only required at SWT side, correct? All they need is to introduce their own reentrant wrappers over standard GTK lock (which is used in gdk_threads_enter/leave, which are already called by AWT) and set them via gdk_threads_set_lock_functions, is this correct?
(In reply to comment #3) > I haven't looked through all the GTK calls in AWT/Swing, but I suspect we don't > need GTK lock reentrancy. As far as I understand your suggestion, the changes > are only required at SWT side, correct? AWT/Swing would need the reentrant lock only if it was calling the GTK event loop calls. My guess is that is not the case. SWT uses those calls. > All they need is to introduce their own > reentrant wrappers over standard GTK lock (which is used in > gdk_threads_enter/leave, which are already called by AWT) and set them via > gdk_threads_set_lock_functions, is this correct? Yes, that is all that is necessary. The wrappers are set in the initialization of both toolkits and gdk_threads_enter/leave() are used to lock around GTK calls. SWT does not make these calls (enter/leave) directly today. So there are more changes in the SWT side. I believe AWT is already calling enter/leave, given that it initializes gtk threads by calling gdk_threads_init(). The wrapper functions could use a GStaticRecMutex. The enter_fn would call g_static_rec_mutex_lock() and the leave_fn would call g_static_rec_mutex_unlock().
> AWT/Swing would need the reentrant lock only if it was calling the GTK event > loop calls. My guess is that is not the case. SWT uses those calls. Correct. AWT/Swing don't use GTK event loops. > Yes, that is all that is necessary. The wrappers are set in the initialization > of both toolkits and gdk_threads_enter/leave() are used to lock around GTK > calls. SWT does not make these calls (enter/leave) directly today. So there > are more changes in the SWT side. I believe AWT is already calling enter/leave, > given that it initializes gtk threads by calling gdk_threads_init(). Correct. AWT/Swing already has gdk_threads_enter/leave calls.
Another related problem bug#341538.
I'm also hitting this problem I believe on Solaris X86 using the Java Desktop Environment. Our application will hang either in the SWT OS.<insert native method here> or in the GTKNativeStyle.native_get_xthickness(int). Has there been any progress on this?
I was able to resolve my issue by sshing into the workstation I was using from the same workstation. Only problem is I have no idea why this works... (In reply to comment #7) > I'm also hitting this problem I believe on Solaris X86 using the Java > Desktop Environment. > > Our application will hang either in the SWT OS.<insert native method here> > or in the GTKNativeStyle.native_get_xthickness(int). Has there been any > progress on this?
It seems this problem is causing the JVM to crash when running my RCP application on Linux (No problems at all on Windows). I have a Swing component embedded in a view through the SWT_AWT bridge, opening the view usually results in a VM crash, most of the time with no error message, but if I get one, it's the following: [xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. java: ../../src/xcb_io.c:178: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed.
(In reply to comment #9) > It seems this problem is causing the JVM to crash when running my RCP > application on Linux (No problems at all on Windows). I have a Swing > component embedded in a view through the SWT_AWT bridge, opening the view > usually results in a VM crash, most of the time with no error message, but > if I get one, it's the following: IIRC, an ugly workaround for this is to specify any Swing L&F other than the GTK one - eg -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel on the launcher config for Linux. I don't have a Linux box to hand to verify, but I think it is what we have on our products to work around the issue.
(In reply to comment #10) > IIRC, an ugly workaround for this is to specify any Swing L&F other than the > GTK one - eg -Dswing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel on > the launcher config for Linux. > > I don't have a Linux box to hand to verify, but I think it is what we have > on our products to work around the issue. Thank you very much for the hint, James! I tested it and the workaround indeed prevents the JVM crash when the view with the embedded Swing component is shown.
Anybody able to solve this bug without setting vm-args ? I have a web start application going through this same difficult phase and I can't set JAVAWS_VM_ARGS swing.defaultlaf inside jnlp .
(In reply to comment #12) > Anybody able to solve this bug without setting vm-args ? > I have a web start application going through this same difficult phase and I > can't set JAVAWS_VM_ARGS swing.defaultlaf inside jnlp . I use a specific class extended from composite everywhere I embed a Swing component. On creation it first calls a method similar to this to initialize the look and feel programmatically: public static void setupLookAndFeel() { if (!lafInitialized) { try { if (Platform.WS_GTK.equals(Platform.getWS())) { // Eclipse Bug 341799 workaround UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel"); } else { UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); } } catch (Exception e) { _log.error(...) } lafInitialized = true; } }
Anybody working on this problem? In my opinion this is a Blocker for SWT with Java Web Start under Linux. There is no chance to set the JAVAWS_VM_ARGS on a client's pc (they get the jnlp URL and that's it).
GTK 4 removes gdk_threads* functions thus closing this one as wontfix as "All GDK and GTK+ calls should be made from the main thread" according to Gtk devs.
