Apache OpenOffice (AOO) Bugzilla – Issue 80684
OOo hangs when adding extension with assistive technologies enabled
Last modified: 2010-01-08 09:16:22 UTC
NOTE: This bug was originally reported here - https://bugzilla.novell.com/show_bug.cgi?id=300489 Test Platforms: openSUSE 10.3 beta1 x86_64 openSUSE 10.3 beta1 i586 NOTE: Used Gnome Desktop on both platforms Tested Build(s): Build OOo OOo-Dev_SRC680_m223_LinuxIntel_install_en-US.tar.gz downloaded from here: http://openoffice.bouncer.osuosl.org/?product=OOo-Dev&os=linuxintel&lang=en-US&version=SRC680_m223 Problem: If the user attempts to add the following extension with the gnome assistive technology enabled (FYI - This is the default with openSUSE 10.3), OOo will hang. Steps to Reproduce - Verify that gnome assistive technology is enabled. If it is not enabled run the following command and then restart the x server once it has been enabled. gnome-at-properties - Launch oowriter - Tools | Extension Manager | Add - Attempt to add the attached oxt extension file - After prompting to accept the license agreement for the extension OOo will hang. NOTE: Sometimes it took two or three times of adding the extension before the application hung. But most of the time I could get it to hang on the first attempt. Expected Behavior User should be able to add extensions with assistive technology enabled without OOo hanging. Work Around: Disable assistive technologies by using gnome-at-properties
Created attachment 47531 [details] test oxt extension file
Oliver, any ideas who would be best here ?
Eric, can you confirm this ?
Yes. Reproduced on Solaris Sparc Nevada snv_68. Always freeze at the second atempt to install the extension. No problem when GTK_MODULES off.
Adjusting prio and target.
Hmm, the main thread waits for the VCL mutex, while some other thread is emitting accessibility events. I am not quite sure yet what this thread is waiting for (somewhere in ORBit code, I assume). current thread: t@12 =>[1] __lwp_park(0x0, 0xf2e78108, 0x0, 0x0, 0xfc00, 0x1), at 0xff2c43e8 [2] cond_sleep_queue(0x3e9508, 0x80a3d0, 0xf2e78108, 0x0, 0x42770, 0x3e9508), at 0xff2bdfc0 [3] cond_wait_queue(0x3e9508, 0x80a3d0, 0xf2e78108, 0xf2c00810, 0x0, 0x669e38a9), at 0xff2be114 [4] cond_wait_common(0x3e9508, 0x80a3d0, 0xf2e78108, 0x0, 0xf2c012d0, 0x0), at 0xff2be570 [5] _cond_timedwait(0x3e9508, 0x80a3d0, 0xf2e78238, 0x0, 0x3, 0x0), at 0xff2be724 [6] cond_timedwait(0x3e9508, 0x80a3d0, 0xf2e78238, 0x0, 0xf2c00800, 0x0), at 0xff2be814 [7] _pthread_cond_timedwait(0x3e9508, 0x80a3d0, 0xf2e78238, 0x41, 0x1, 0xf2e78238), at 0xff2be854 [8] g_cond_timed_wait_posix_impl(0x3e9508, 0x80a3d0, 0x8b2ce8, 0x8a0fe0, 0x11d08, 0xfcf735d0), at 0xfcf61930 [9] giop_recv_buffer_get(0xf2e78308, 0xf2e78320, 0x0, 0x1, 0xf8fe314c, 0x10ffc8), at 0xf8fa46a4 [10] ORBit_small_invoke_stub(0x0, 0xf9087d2c, 0x0, 0xf2e78404, 0x0, 0xf90b5f04), at 0xf8fa877c [11] ORBit_c_stub_invoke(0xc5600, 0xf9087e78, 0x0, 0x0, 0xf2e78404, 0x0), at 0xf8fbdf98 [12] Accessibility_EventListener_notifyEvent(0xc5600, 0xf2e7846c, 0xf90b5f04, 0x264, 0x37b84, 0x0), at 0xf904d894 [13] spi_atk_emit_eventv(0x5c4ac0, 0x0, 0xf90b5eb4, 0x0, 0x45cb68, 0x804290), at 0xf90a3c7c [..]
urk - likely to be a disaster area then :-) it'd be good to get a nice trace of both threads, so we can start to unwind the deadlock.
Created attachment 47587 [details] Full stack trace (deskop/source/deployment with full debug info)
Hokay - so it seems: Thread <12> + Waiting from reply of 'notifyEvent': [9] libORBit-2.so.0.1.0:giop_recv_buffer_get(0xf2e78728, 0xf2e78740, 0x0, 0x1, 0xf8fe314c, 0x3e7c80), at 0xf8fa46a4 ...[12] libspi.so.0.10.11:Accessibility_EventListener_notifyEvent(0xc5600, 0xf2e7888c, 0xf90b5f04, 0x264, 0x37b84, 0x0), at 0xf904d894 [13] libatk-bridge.so:spi_atk_emit_eventv(0x5b8320, 0x0, 0xf90b5eb4, 0xf2e7890c, 0xf90a5748, 0x803550), at 0xf90a3c7c [14] libatk-bridge.so:spi_atk_bridge_window_event_listener(0xf2e789ec, 0xf9719dbc, 0xf2e78b58, 0x10d10, 0xf90b5764, 0x10000), at 0xf90a4adc emitting focus event from at-spi/atk-bridge ... ...[18] libgail.so:window_focus(0x167800, 0xfffefc48, 0x5b8320, 0x186d0, 0xfcb654d4, 0x10000), at 0xfcb5d27c ... from here [32] libvclplug_gen680ss.so:X11SalInstance::Yield(0xfe914c10, 0x1, 0x0, 0xfcd20ee8, 0xf5c, 0xc00), at 0xfcce3ac0 [33] libvcl680ss.so:Application::Yield(0x0, 0xfe914c10, 0x0, 0xfe909d24, 0x238c, 0xfe914c24), at 0xfe61e938 [34] libvcl680ss.so:Dialog::Execute(0x817b80, 0xfe926338, 0xf2e79338, 0xf2e796a8, 0xfe909d24, 0x0), at 0xfe791928 [35] deploymentgui680ss.uno.so:dp_gui::LicenseDialog::execute(this = ???) (optimized), at 0xf470bc68 Is deadlocking against this guy: [3] libuno_sal.so.3:osl_acquireMutex(0x82ca8, 0x86a98, 0x1, 0x0, 0x0, 0x82ca8), at 0xfd51db10 [4] libvos3C52.so:vos::OMutex::acquire(0xfe566068, 0x0, 0xfe972a00, 0x1, 0x3, 0x0), at 0xff050694 [5] libvclplug_gen680ss.so:SalYieldMutex::acquire(0xfe566068, 0x0, 0xff000000, 0xff000000, 0x0, 0xff000000), at 0xfcce355c [6] 0xfcf966d8(0xfe566068, 0x0, 0xff305c80, 0xfe972a00, 0x0, 0x0), at 0xfcf966d8 [10] libvcl680ss.so:Application::Yield(0x0, 0xfe914c10, 0x0, 0xfe909d24, 0x238c, 0xfe914c24), at 0xfe61e938 [11] libvcl680ss.so:Application::Execute(0x1, 0xfe914c10, 0x0, 0xfe909d24, 0x238c, 0x2000), at 0xfe61e7cc [12] soffice.bin:desktop::Desktop::Main(0xffbfeec0, 0xf5d9878c, 0x1, 0xffbfed64, 0x0, 0xffbfeb84), at 0x2c08c [13] 0xfe62584c(0x0, 0xffbfeebc, 0x1, 0x0, 0xfe909d24, 0xfe914c24), at 0xfe62584c So - I suspect that the AT is simply trying to call back into the process in order to ask some questions about the event: "What object", "How long", "Whodunnit?" that sort of thing and it can't get in... The real question is: what to do about it ;-)
Actually there is no real AT involved, but looking at the stack of at-spi-registryd makes me think the incoming request for thread 1 might be a temporary AddRef for queuing the event of thread 12: [7] giop_recv_buffer_get(0xffbfa7e8, 0xffbfa800, 0x1, 0x1, 0xfefe314c, 0x2d490), at 0xfefa4544 [8] ORBit_small_invoke_stub(0x0, 0xff1f4508, 0x0, 0x0, 0x0, 0xffbfa944), at 0xfefa877c [9] ORBit_c_stub_invoke(0x7c9d0, 0xff1f45d0, 0x0, 0x0, 0x0, 0x0), at 0xfefbdf98 [10] Bonobo_Unknown_ref(0x7c9d0, 0xffbfa944, 0xd4, 0x1946c, 0x0, 0xff1f38d0), at 0xff1da4c8 [11] bonobo_object_dup_ref(0x7c9d0, 0x0, 0x1c38, 0xffbfa944, 0xff0b8684, 0x7c9d0), at 0xfedab1d0 [12] registry_clone_notify_context(0xffbfaa78, 0xffbfaa78, 0x2b000, 0x74268, 0x97188, 0x3), at 0x198a0 [13] registry_queue_event(0x37c18, 0xffbfaa78, 0xffbfaca4, 0xfef12a00, 0x1, 0x1), at 0x19bb4 [14] impl_registry_notify_event(0x37c2c, 0x7b858, 0xffbfaca4, 0x5, 0x2b000, 0x2b388), at 0x19cf0 [15] ORBit_small_invoke_adaptor(0x561a0, 0x7b7d8, 0x0, 0xffbfab00, 0xffbfaca4, 0xff267d2c), at 0xfefa8f90
sure; the question really is - how can we process incoming calls, when the other thread holds the VCL mutex. I think it's likely that we need to drop the GDK_THREADS mutex in the atk-bridge before the CORBA event emission. On the other hand, now I read gail & atk-bridge we fixed this bug already in HEAD - I wonder what version that is in. Perhaps we should just bump our version requirement for full a11y (?). 2007-01-08 Bill Haneman <bill.haneman@sun.com> * configure.in: Depend on ATK-1.13.0 (because of new AtkMisc usage). Rev to 1.9.5. * gail/gailutil.c: (gail_misc_class_init): New, implement AtkMisc. (gail_misc_threads_enter): Call GDK_THREADS_ENTER(). (gail_misc_threads_leave): Call GDK_THREADS_LEAVE(). See bug #329454.
Ah, almost forgot about that one (link added to URL field). So the freeze happens because incoming calls are always processed by the main thread, but the extension manager does UI in some other thread ? @kr: will the UNO threading framework change anything in this scenario ?
> So the freeze happens because incoming calls are always processed by the main > thread, but the extension manager does UI in some other thread ? for various back-compat reasons yes :-) although, in theory there is little reason why that has to be so. Nevertheless the gail/atk-bridge fixes will fix this for OO.o as it is now: since (via the vcl<->gdk lock synchronisation) the gtk+ code can drop the SolarMutex :-)
nurk - it turns out that (in fact) this is still broken with the latest gail/atk - so, more thinking is required. I'll try to harvest some new traces there later.
@jl: after discussing this issue with kr, the only viable solution seems to be to deligate the execute of the license dialog to the main thread using vcl::SolarThreadExecutor::impl_execute and vcl::solarthread::detail::GenericSolarThreadExecutor like it is already done for the file picker.
.
This may also the affect the update window and the download&install window of the extensions manager. Retargeting to 3.0.
md: added mself to cc
Setting target to 2.4
License dialog is now started in the event dispatcher thread. The update dialog is started in the button event handler. Therefore it should not be affected.
jl->es: Please verify. You can also use the test extensions at desktop/test/deployment/simple_license (for example, local1.oxt .. local6.oxt).
Verified in CWS jl87
Fixed and integrated => closing now..