Apache OpenOffice (AOO) Bugzilla – Issue 111006
toolkit: deadlock between UnoControls
Last modified: 2013-01-29 21:40:15 UTC
Executing forms/qa/unoapi on DEV300_m76-based CWS sb120 produced a deadlock on both unxsoli4 non-pro (see attached stack.txt) and wntmsci12. In both cases, the tail of the unoapi output is checking: [forms.OFileControlModel::com::sun::star::beans::XFastPropertySet] is iface: [com.sun.star.beans.XFastPropertySet] testcode: [ifc.beans._XFastPropertySet] LOG> Execute: setFastPropertyValue() LOG> Checking 'Align' with handle = 63 LOG> Checking 'BackgroundColor' with handle = 58 LOG> Checking 'Border' with handle = 62 LOG> Checking 'BorderColor' with handle = 10000 LOG> Checking 'ClassId' with handle = 9 LOG> Checking 'ContextWritingMode' with handle = 21 As annotated in the attached stack.txt, it appears that t@1 holds the maMutex of the UnoControlContainer parent and wants to lock the maMutex of the added child, while t@71 holds the maMutex of the child and wants to lock the maMutex of the parent container. See issue 109939 for a related, general discussion of UnoControl locks. This deadlock appeared (both on unxsoli4 and wntmsci12) when the fix for issue 109916 ("frm::OInterfaceContainer::fakeVbaEventsHack deadlock") was included. This might be a coincidence, or a problem with the fix for issue 109916.
Created attachment 69009 [details] unxsoli4 deadlock
worked around for now by disabling the affected tests in forms/qa/unoapi/knownissues.xcl, see <http://hg.services.openoffice.org/cws/sb120/rev/12e79c459406>; please revert when fixing this issue