Bug 20430 - LDTP locks up when referenceing a gconf client in script
Summary: LDTP locks up when referenceing a gconf client in script
Status: RESOLVED DUPLICATE of bug 20119
Alias: None
Product: at-spi2
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Li Yuan
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-02 11:41 UTC by Eitan Isaacson
Modified: 2010-01-24 08:38 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Example script. (740 bytes, text/plain)
2009-03-02 11:41 UTC, Eitan Isaacson
Details
pthread_mutex_* commented code (3.03 KB, text/plain)
2009-03-03 11:35 UTC, Nagappan Alagappan
Details
Working version (950 bytes, text/plain)
2009-04-06 09:22 UTC, Eitan Isaacson
Details

Description Eitan Isaacson 2009-03-02 11:41:44 UTC
Created attachment 23449 [details]
Example script.

When referencing a gconf client in a test script, LDTP locks up. This happens when querying for waittillguiexist of waittillguinotexist.

In the attached script, simply comment out the client_get_default() line to get it working again.
Comment 1 Nagappan Alagappan 2009-03-03 11:33:42 UTC
Guess the issue is in cspi library. Even If I comment all the pthread_mutex_* calls, I could still reproduce this issue

Thread 4 (Thread 0xb798fb90 (LWP 13564)):
#0  0xb8089430 in __kernel_vsyscall ()
#1  0xb7c24167 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0x0804c907 in ldtp_server_thread (ptr=0x0) at ldtp.c:400
#3  0xb7e0d50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#4  0xb7c2ea0e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 3 (Thread 0xb714eb90 (LWP 13579)):
#0  0xb8089430 in __kernel_vsyscall ()
#1  0xb7e11075 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/tls/i686/cmov/libpthread.so.0
#2  0xb7cdd8a5 in giop_recv_buffer_get () from /usr/lib/libORBit-2.so.0
#3  0xb7ce2816 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#4  0xb7ce2a49 in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#5  0xb7cef7aa in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#6  0xb7dc39f3 in Accessibility_Accessible_getChildAtIndex (_obj=0x95b1f40, index=9, ev=0xb7e06610) at Accessibility-stubs.c:189
#7  0xb7dfc51a in Accessible_getChildAtIndex (obj=0x0, childIndex=9) at spi_accessible.c:422
#8  0x08053283 in get_window_handle (app_handle=0x0, app_name=0x0, context=0x95b47f0 "*-gedit", window_name=0xb714e340, flag=0x0) at ldtp-gui.c:1248
#9  0x0804d76c in update_context_name (cctxt=0x95b21b8) at client-handler.c:768
#10 0x0804ea06 in handle_client (ptr=0x11) at client-handler.c:1032
#11 0xb7e0d50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#12 0xb7c2ea0e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 2 (Thread 0xb694db90 (LWP 13584)):
#0  0xb8089430 in __kernel_vsyscall ()
#1  0xb7c24167 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e5cc32 in g_main_context_iterate (context=0x95b3080, block=1, dispatch=1, self=0x95b3100) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:3091
#3  0xb7e5d2c2 in IA__g_main_loop_run (loop=0x95b2058) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2986
#4  0xb7cfb8b0 in ?? () from /usr/lib/libORBit-2.so.0
#5  0xb7e8402f in g_thread_create_proxy (data=0x95b3100) at /build/buildd/glib2.0-2.18.2/glib/gthread.c:635
#6  0xb7e0d50f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#7  0xb7c2ea0e in clone () from /lib/tls/i686/cmov/libc.so.6

Thread 1 (Thread 0xb79906b0 (LWP 13563)):
#0  0xb8089430 in __kernel_vsyscall ()
#1  0xb7c24167 in poll () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e5cc32 in g_main_context_iterate (context=0x95a0d90, block=1, dispatch=1, self=0x959b1a0) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:3091
#3  0xb7e5d2c2 in IA__g_main_loop_run (loop=0x95b2080) at /build/buildd/glib2.0-2.18.2/glib/gmain.c:2986
#4  0xb7d65cf3 in bonobo_main () from /usr/lib/libbonobo-2.so.0
#5  0xb7e029f7 in cspi_main () at cspi-bonobo.c:192
#6  0xb7dff1b7 in SPI_event_main () at spi_main.c:406
#7  0x0804c006 in main (argc=808268336, argv=0xbfb88cf4) at ldtp.c:634
#0  0xb8089430 in __kernel_vsyscall ()
Comment 2 Nagappan Alagappan 2009-03-03 11:35:43 UTC
Created attachment 23482 [details]
pthread_mutex_* commented code

Just that I have commented all the pthread_mutex_* calls :)
Comment 3 Eitan Isaacson 2009-04-06 09:21:29 UTC
I resolved this issue. It seems that the script itself is registered as an application in the AT-SPI registry. Since there is not event loop in the duration of the script, it blocks an attempt by the ldtp process to retrieve a list of all applications on the desktop. The gonf operations probably perform a few mainloop iterations, and thus get the script registered. I am right now writing a few test cases that use a similar technique to wait for events.

The solution is to make sure that accessibility is disabled for the script. In pre-GNOME 2.24 this means unsetting GTK_MODULES. In post GNOME-2.24 this means setting NO_GAIL and NO_ATK_BRIDGE to "1".

The gotcha is that at target app launch-time the accessibility environment bits need to be in order...
Comment 4 Eitan Isaacson 2009-04-06 09:22:28 UTC
Created attachment 24608 [details]
Working version
Comment 5 Mark Doffman 2009-04-29 00:50:50 UTC
Without a GMainLoop it should be impossible for the ATK Bridge to register itself as an accessible application. 

At startup the application sends a D-Bus signal to the registryd to register the application. On starting up the pyatspi library it makes a D-Bus method call to get hold of the D-Bus names of all accessible applications.

ATM if the test script is loaded as an accessible application this will cause problems. There is no re-entrancy in the pyatspi library meaning that things will lock-up if the script tries to investigate itself. 

This is listed in http://bugs.freedesktop.org/show_bug.cgi?id=20119.

If there isn't a work-around for this in LDTP we should mark as a duplicate of the above bug. (There is no particular reason why a test script would want to make itself accessible)  
Comment 6 Mark Doffman 2010-01-24 08:38:24 UTC
Marking as duplicate of 20119, Re-entrancy issue, now partially resolved.

*** This bug has been marked as a duplicate of bug 20119 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.