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 682473 - Deadlock when using org.gnome.gtk.Application
Deadlock when using org.gnome.gtk.Application
Status: RESOLVED FIXED
Product: java-gnome
Classification: Bindings
Component: GTK
mainline
Other Linux
: Urgent critical
: 4.1.2
Assigned To: java-gnome bindings maintainers
java-gnome bindings maintainers
Depends on:
Blocks: 658400
 
 
Reported: 2012-08-22 13:47 UTC by Guillaume Mazoyer
Modified: 2012-09-02 12:56 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Code to reproduce (1.62 KB, text/x-java)
2012-08-22 13:47 UTC, Guillaume Mazoyer 		Details

Description Guillaume Mazoyer 2012-08-22 13:47:06 UTC 
Created attachment 222150 [details]
Code to reproduce

When using the brand new application calling GTK from another thread will make it block. I hava attached a code to reproduce the bug. So basically, the bindings do not look to be thread-safe while using org.gnome.gtk.Application. The bug does not appear if the code uses the classic Gtk.main().

Here is the thread state when trying to call a GTK method of the attachment.

"Thread-0" prio=10 tid=0x00007f9798308800 nid=0x126d waiting for monitor entry [0x00007f979c10f000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.gnome.gtk.GtkLabel.setLabel(GtkLabel.java:161)
	- waiting to lock <0x00000000ebcfcaf8> (a org.gnome.gdk.Gdk$Lock)
	at org.gnome.gtk.Label.setLabel(Label.java:114)
	at DeadlockExample$Worker.run(DeadlockExample.java:22)
Comment 1 Andrew Cowie 2012-08-23 00:45:25 UTC 
Yeah, duplicated in Slashtime.

Bloody hell.

GTK thread safety is deprecated and shortly to be removed; it looks like they didn't implement releasing the GDK lock in g_application_run() the way they do in gtk_main().

AfC