Bug 226959 - [a11y] [at-spi vs gij] sample program fails to exit, regression since FC-6
[a11y] [at-spi vs gij] sample program fails to exit, regression since FC-6
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: at-spi (Show other bugs)
rawhide
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthias Clasen
: Reopened
: 208910 230053 230901 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-02 04:24 EST by Caolan McNamara
Modified: 2007-11-30 17:11 EST (History)
6 users (show)

See Also:
Fixed In Version: 1.18.0-1.f7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-14 12:04:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
demo case (1.80 KB, application/octet-stream)
2007-02-02 04:25 EST, Caolan McNamara
no flags Details
ok case (257.93 KB, text/plain)
2007-03-12 05:25 EDT, Caolan McNamara
no flags Details
and the not ok log (275.05 KB, text/plain)
2007-03-12 05:26 EDT, Caolan McNamara
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
OpenOffice.org 404592 None None None Never

  None (edit)
Description Caolan McNamara 2007-02-02 04:24:30 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20070130 Firefox/2.0.0.1

Description of problem:
Take the attached .class

on FC-6 gij JREProperties will spew some numbers and exit
on rawhide libgcj-4.1.1-54 JREProperties will spew the same numbers but fail to exit

Version-Release number of selected component (if applicable):
libgcj-4.1.1-54

How reproducible:
Always


Steps to Reproduce:
1. Take attachment
2 [details]. gij JREProperties

Actual Results:
hang

Expected Results:
exit normally

Additional info:
ok with libgcj-4.1.1-51.fc6
Comment 1 Caolan McNamara 2007-02-02 04:25:28 EST
Created attachment 147203 [details]
demo case
Comment 3 Caolan McNamara 2007-02-21 14:14:49 EST
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.
Comment 5 Andrew Haley 2007-02-21 14:31:37 EST
 $ 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)

Comment 6 Andrew Haley 2007-02-21 15:01:23 EST
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)
Comment 7 Caolan McNamara 2007-02-26 06:17:00 EST
*** Bug 230053 has been marked as a duplicate of this bug. ***
Comment 8 Jakub Jelinek 2007-02-26 06:21:45 EST
Can you still reproduce it with the latest dist-fc7 gcc (gcc-4.1.2-3)?
libjava changed substantially there.
Comment 9 Jakub Jelinek 2007-02-28 10:58:31 EST
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).
Comment 10 Caolan McNamara 2007-02-28 11:06:19 EST
works for me as well now with 4.1.2-3
Comment 11 Caolan McNamara 2007-03-04 09:56:16 EST
*** Bug 230901 has been marked as a duplicate of this bug. ***
Comment 12 Caolan McNamara 2007-03-05 09:15:18 EST
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
Comment 13 Andrew Haley 2007-03-05 09:18:03 EST
Tell me how to reproduce that and I'll have a look.
Comment 14 Caolan McNamara 2007-03-05 09:32:14 EST
GNOME: system->preferences->personal->assistive technology preferences->enable

logout, login

/usr/bin/gij -classpath /usr/lib64/openoffice.org/program JREProperties
Comment 16 Jakub Jelinek 2007-03-12 05:12:49 EDT
Can you strace -f it with and without a11y enabled and attach strace outputs
here?
Comment 17 Caolan McNamara 2007-03-12 05:25:38 EDT
Created attachment 149808 [details]
ok case
Comment 18 Caolan McNamara 2007-03-12 05:27:00 EDT
Created attachment 149809 [details]
and the not ok log
Comment 19 Andrew Haley 2007-03-12 11:01:40 EDT
(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

Comment 21 Jakub Jelinek 2007-03-12 13:43:51 EDT
exit doesn't ever call pthread_mutex_lock directly, so gdk_threads_enter or
what must have done a tail call.
Comment 22 Andrew Haley 2007-03-12 15:29:03 EDT
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.


Comment 23 Andrew Haley 2007-03-12 15:30:12 EDT
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
Comment 24 Caolan McNamara 2007-03-13 04:38:28 EDT
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.
Comment 25 Caolan McNamara 2007-03-14 12:04:11 EDT
upgrading to todays at-spi seems to have cleared this with a11y enabled under x86_64
Comment 26 Thomas Fitzsimmons 2007-04-02 14:01:58 EDT
*** Bug 208910 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.