With periodical thread switching (if uncomment threadswitch line) it almost never hangs. Actually even the default blank application may hang (as was written above) but very very rarely. With heavy thread the effect is almost always when run the app from command line [now using Ubuntu 16.0 x64 on Vmware].
I attached to the frozen app and got stack traces. Maybe this may help somehow.
Thread 1
#0 syscall at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
#1 ?? at :0
#2 g_dbus_connection_send_message_with_reply at :0
#3 ?? at :0
#4 g_dbus_connection_call at :0
#5 ?? at :0
#6 ?? at :0
#7 g_initable_new_valist at :0
#8 g_initable_new at :0
#9 gvfs_dbus_mount_tracker_proxy_new_for_bus_sync at :0
#10 ?? at :0
#11 ?? at :0
#12 g_type_create_instance at :0
#13 ?? at :0
#14 g_object_newv at :0
#15 g_object_new at :0
#16 ?? at :0
#17 ?? at :0
#18 g_file_new_for_path at :0
#19 ?? at :0
#20 g_type_create_instance at :0
#21 ?? at :0
#22 ?? at :0
#23 ?? at :0
#24 g_object_new_valist at :0
#25 g_object_new at :0
#26 ibus_bus_new_async at :0
#27 ?? at :0
#28 g_type_class_ref at :0
#29 g_object_newv at :0
#30 g_object_new at :0
#31 ibus_im_context_new at :0
#32 ?? at :0
#33 ?? at :0
#34 ?? at :0
#35 RESETDEFAULTIMCONTEXT at gtk2/gtk2globals.pp:422
#36 GTKFOCUSCB(0x172e360, 0x177f6e0, 0x17deef8) at gtk2/gtk2callback.inc:1038
#37 GTK2FOCUSCB(0x172e360, 0x177f6e0, 0x17dbfb8) at gtk2/gtk2widgetset.inc:54
#38 ?? at :0
#39 g_closure_invoke at :0
#40 ?? at :0
#41 g_signal_emit_valist at :0
#42 g_signal_emit at :0
#43 ?? at :0
#44 gtk_main_do_event at :0
#45 ?? at :0
#46 g_main_context_dispatch at :0
#47 ?? at :0
#48 g_main_context_iteration at :0
#49 gtk_main_iteration_do at :0
#50 APPPROCESSMESSAGES(0x16b05a8) at gtk2/gtk2widgetset.inc:2318
#51 HANDLEMESSAGE(0x16ae378) at include/application.inc:1262
#52 RUNLOOP(0x16ae378) at include/application.inc:1399
#53 APPRUN(0x16b05a8, {Proc = {procedure (POINTER)} 0x7ffd4333b350, Self = 0x16ae378}) at include/interfacebase.inc:54
#54 RUN(0x16ae378) at include/application.inc:1387
#55 main at project1.lpr:19
Thread 2
#0 poll at ../sysdeps/unix/syscall-template.S:84
#1 ?? at :0
#2 g_main_context_iteration at :0
#3 ?? at :0
#4 ?? at :0
#5 start_thread(0x7f63c9058700) at pthread_create.c:333
#6 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 3
#0 poll at ../sysdeps/unix/syscall-template.S:84
#1 ?? at :0
#2 g_main_context_iteration at :0
#3 ?? at :0
#4 ?? at :0
#5 start_thread(0x7f63c8857700) at pthread_create.c:333
#6 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
Thread 4
#0 __lll_lock_wait at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 __GI___pthread_mutex_lock(0x16c7f90) at ../nptl/pthread_mutex_lock.c:115
#2 g_type_class_ref at :0
#3 g_object_newv at :0
#4 g_object_new at :0
#5 ?? at :0
#6 ?? at :0
#7 ?? at :0
#8 ?? at :0
#9 ?? at :0
#10 ?? at :0
#11 ?? at :0
#12 g_main_context_dispatch at :0
#13 ?? at :0
#14 g_main_loop_run at :0
#15 ?? at :0
#16 ?? at :0
#17 start_thread(0x7f63c3fff700) at pthread_create.c:333
#18 clone at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
For thread 1 there may be different functions between #0 syscall and g_type_create_instance at :0 but others are the same between runs.