Bug 226959

Created attachment 147203 [details]
demo case

libgcj-4.1.2-1, seems ok on i386 now, but still hangs on x86_64 i.e.

/usr/bin/gij -classpath /usr/lib64/openoffice.org/program JREProperties

The upshot of this is that OOo will hang waiting for gij to complete running the
above for any fresh install that doesn't have a ~/.openoffice.org2.0 dir.

 $ gij JREProperties
112 97 116 104 46 115 101 112 97 114 97 116 111 114 61 58 
106 97 118 97 46 118 109 46 110 97 109 101 61 71 78 85 32 108 105 98 103 99 106 
106 97 118 97 46 118 109 46 115 112 101 99 105 102 105 99 97 116 105 111 110 46
110 97 109 101 61 74 97 118 97 40 116 109 41 32 86 105 114 116 117 97 108 32 77
97 99 104 105 110 ... [lots more numbers]
 $ uname -a
Linux zebedee.pink 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:39:22 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux
 $ gij --version
java version "1.5.0"
gij (GNU libgcj) version 4.1.1 20070202 (Red Hat 4.1.1-55)

And with a new gij:

 $ gij JREProperties       
112 97 116 104 46 115 101 112 97 114 97 116 111 114 61 58 
106 97 118 97 46 118 109 46 110 97 109 101 61 71 78 85 32 108 105 98 103 99 106 
106 97 118 97 46 118 109 46 115 112 101 99 105 ...
 $ gij --version    
java version "1.5.0"
gij (GNU libgcj) version 4.1.2 20070214 (Red Hat 4.1.2-1)

*** Bug 230053 has been marked as a duplicate of this bug. ***

Can you still reproduce it with the latest dist-fc7 gcc (gcc-4.1.2-3)?
libjava changed substantially there.

I can't reproduce this with either:
LD_PRELOAD=/home/jakub/4.1.2-1/usr/lib64/libgcj.so.7rh:/home/jakub/4.1.2-1/usr/lib64/libgij.so.7rh /home/jakub/4.1.2-1/usr/bin/gij JREProperties
or
LD_PRELOAD=/home/jakub/4.1.2-3/usr/lib64/libgcj.so.8rh:/home/jakub/4.1.2-3/usr/lib64/libgij.so.8rh /home/jakub/4.1.2-3/usr/bin/gij JREProperties
(x86_64 in both cases).

works for me as well now with 4.1.2-3

*** Bug 230901 has been marked as a duplicate of this bug. ***

Apparently need to have accessibility enabled to reproduce this problem. With
a11y enabled I can see it with 4.1.2-3 on x86_64

Tell me how to reproduce that and I'll have a look.

GNOME: system->preferences->personal->assistive technology preferences->enable

logout, login

/usr/bin/gij -classpath /usr/lib64/openoffice.org/program JREProperties

Can you strace -f it with and without a11y enabled and attach strace outputs
here?

Created attachment 149808 [details]
ok case

Created attachment 149809 [details]
and the not ok log

(gdb) thread apply all bt

Thread 2 (Thread 1084229952 (LWP 17960)):
#0  0x00000036c060a2d6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib64/libpthread.so.0
#1  0x0000003e89736550 in _Jv_CondWait () from /usr/lib64/libgcj.so.8rh
#2  0x0000003e8971d7f1 in gnu::gcj::runtime::FinalizerThread::run () from
/usr/lib64/libgcj.so.8rh
#3  0x0000003e8972e50f in _Jv_ThreadRun () from /usr/lib64/libgcj.so.8rh
#4  0x0000003e89735d97 in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#5  0x0000003e89fc28d6 in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#6  0x00000036c06061b5 in start_thread () from /lib64/libpthread.so.0
#7  0x00000036bf2cdd4d in clone () from /lib64/libc.so.6

Thread 1 (Thread 46912496221904 (LWP 17959)):
#0  0x00000036c060c6c8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0
#1  0x00000036c0608724 in _L_mutex_lock_103 () from /lib64/libpthread.so.0
#2  0x00000036c06081c3 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x00000036bf2331f9 in exit () from /lib64/libc.so.6
#4  0x0000003e8972b019 in java::lang::Runtime::exitInternal () from
/usr/lib64/libgcj.so.8rh
#5  0x0000003e89b02d07 in java::lang::Runtime::exitNoChecks () from
/usr/lib64/libgcj.so.8rh
#6  0x0000003e89b100af in java::lang::System::exit () from /usr/lib64/libgcj.so.8rh
#7  0x0000003e89fb217c in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#8  0x0000003e89fb2008 in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#9  0x0000003e89fb138b in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#10 0x0000003e89709da5 in _Jv_InterpMethod::run () from /usr/lib64/libgcj.so.8rh
#11 0x0000003e89fb148f in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#12 0x0000003e89fb1a66 in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#13 0x0000003e89fb22a8 in _Jv_RegisterClasses () from /usr/lib64/libgcj.so.8rh
#14 0x0000003e8971e092 in gnu::java::lang::MainThread::call_main () from
/usr/lib64/libgcj.so.8rh
#15 0x0000003e8972e50f in _Jv_ThreadRun () from /usr/lib64/libgcj.so.8rh
#16 0x0000003e896ed22d in _Jv_RunMain () from /usr/lib64/libgcj.so.8rh
#17 0x0000003e8b000c1d in main () from /usr/lib64/libgij.so.8rh
#18 0x00000036bf21d9c4 in __libc_start_main () from /lib64/libc.so.6
#19 0x00000000004005c9 in _Jv_RegisterClasses ()
#20 0x00007fff2f397d08 in ?? ()
#21 0x0000000000000000 in ?? ()
#0  0x00000036c060c6c8 in __lll_mutex_lock_wait () from /lib64/libpthread.so.0

exit doesn't ever call pthread_mutex_lock directly, so gdk_threads_enter or
what must have done a tail call.

The real bug seems to be here in at-spi-1.17.2/atk-bridge/bridge.c:

  static void
  spi_atk_bridge_register_application (Accessibility_Registry registry)
  {
   atk_misc_threads_leave (misc);
    Accessibility_Registry_registerApplication (spi_atk_bridge_get_registry (),
                                                BONOBO_OBJREF (this_app),
                                                &ev);
    atk_misc_threads_enter (misc);
    if (ev._major != CORBA_NO_EXCEPTION)
      CORBA_exception_free (&ev);
  }

When this function is entered, the lock used by gdk_threads_enter() is not held.
 When this function returns, that lock is held.

atk_misc_threads_leave() calls 

static void gail_misc_threads_leave (AtkMisc *misc)
{
  GDK_THREADS_LEAVE ();
}

but this has no effect because this thread does not hold the gdk mutex -- it is
free.  However, the later call to atk_misc_threads_enter() succeeds, locking the
gdk mutex.

Here is the stack trace at the point at which the gdk mutex is locked:

#0  gail_misc_threads_enter (misc=0x666ec0) at gailutil.c:652
#1  0x00002aaaaf407cef in spi_atk_bridge_register_application (registry=<value
optimized out>) at bridge.c:318
#2  0x00002aaaaf408289 in spi_atk_bridge_do_registration () at bridge.c:271
#3  0x00002aaaaf409b49 in atk_bridge_init (argc=0x3860d8183c, argv=0x3860d81840)
at bridge.c:231
#4  0x000000386094321b in default_display_notify_cb (display_manager=<value
optimized out>) at gtkmodules.c:413
#5  0x00002aaaaead2f19 in IA__g_closure_invoke (closure=0x620200,
return_value=0x0, n_param_values=2, param_values=0x7fffee5851d0,
invocation_hint=0x7fffee585090) at gclosure.c:490
#6  0x00002aaaaeae2788 in signal_emit_unlocked_R (node=0x62b4b0, detail=58,
instance=0x62aa40, emission_return=0x0, instance_and_params=0x7fffee5851d0) at
gsignal.c:2440
#7  0x00002aaaaeae3bd4 in IA__g_signal_emit_valist (instance=0x62aa40,
signal_id=<value optimized out>, detail=58, var_args=0x7fffee585450) at
gsignal.c:2199
#8  0x00002aaaaeae3da3 in IA__g_signal_emit (instance=0x666ec0,
signal_id=1663348611, detail=35) at gsignal.c:2243
#9  0x00002aaaaead6cff in g_object_dispatch_properties_changed (object=0x62aa40,
n_pspecs=1, pspecs=0x7fffee585560) at gobject.c:563
#10 0x00002aaaaead8656 in IA__g_object_notify (object=0x62aa40,
property_name=<value optimized out>) at gobjectnotifyqueue.c:123
#11 0x0000003860e19ad5 in IA__gdk_display_open_default_libgtk_only () at gdk.c:289
#12 0x000000386092d4e4 in IA__gtk_init_check (argc=<value optimized out>,
argv=<value optimized out>) at gtkmain.c:889
#13 0x000000386092d509 in IA__gtk_init (argc=0x666ec0, argv=0x386324af83) at
gtkmain.c:924

at-spi version 1.17.2-1.fc7. Maybe of note is that 227245 is an older apparently
fixed similar at-spi and threading problem.

upgrading to todays at-spi seems to have cleared this with a11y enabled under x86_64

*** Bug 208910 has been marked as a duplicate of this bug. ***