|
Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
| Summary: | sw/qa/unoapi sw.SwXTextRange hangs | ||
|---|---|---|---|
| Product: | gsl | Reporter: | Stephan Bergmann <stephan.bergmann.secondary> |
| Component: | code | Assignee: | AOO issues mailing list <issues> |
| Status: | CONFIRMED --- | QA Contact: | |
| Severity: | Trivial | ||
| Priority: | P3 | CC: | issues, mst.ooo |
| Version: | DEV300m84 | ||
| Target Milestone: | OOo 3.x | ||
| Hardware: | All | ||
| OS: | All | ||
| Issue Type: | DEFECT | Latest Confirmation in: | --- |
| Developer Difficulty: | --- | ||
|
Description
Stephan Bergmann
2010-07-16 14:19:47 UTC
so we have one thread that has the SolarMutex locked and wants to do something with X11, one thread where a GDK event is coming in, and another thread that looks like somebody wants to look at the clipboard. thread t@98 seems to be in some generic paint code that could be called by probably half of the writer UNO API. so disabling any specific test does not look like a good idea to me; this deadlock could probably occur anywhere in the writer API. it seems to me that the interaction with X11 here is the problem, so i'll assign it to pl, who likely as a relevant opinion about this problem. Experienced a similar hang on DEV300_m84 based CWS sb127 under unxsols4 non-pro in sd/qa/unoapi [...] 20: Creating: sd.SdMasterPage 20: LOG> Log started 20.06.2010 - 02:35:52 20: LOG> creating a draw document 20: LOG> creating a test environment 20: LOG> getting MasterPages 20: LOG> getting MasterPage 20: LOG> inserting some Shapes with (dbx) where t@1 current thread: t@1 =>[1] __pollsys(0x4, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xff2ca634 [2] _pollsys(0xffbfbcd0, 0x1, 0x0, 0x0, 0x0, 0x0), at 0xff2ba32c [3] _pselect(0xffbfbcd0, 0xff342630, 0xff342630, 0x40, 0x0, 0x0), at 0xff267b68 [4] _select(0x7, 0xffbfbdd8, 0x0, 0x0, 0x0, 0x347e0), at 0xff267ee0 [5] _XWaitForReadable(0x34110, 0x40, 0x6, 0xffbfbdd8, 0x1, 0x0), at 0xfbe9f114 [6] _XRead(0xffffffff, 0xffbfc058, 0x800, 0x34110, 0x20, 0x6c0), at 0xfbe9ef44 [7] _XEatData(0x34110, 0x800, 0x0, 0x0, 0x0, 0x26c6898), at 0xfbed6b38 [8] _XGetAsyncReply(0x34110, 0xffbfc7d8, 0x0, 0x34850, 0x20, 0x0), at 0xfbea07c0 [9] set_input_focus_handler(0x34110, 0x34850, 0x34850, 0x20, 0xe201a8, 0x34110), at 0xfd1b46d4 [10] _XAsyncReply(0x34110, 0x34850, 0x34850, 0xffbfc93c, 0x1, 0x20), at 0xfbea05c8 [11] _XEventsQueued(0x34110, 0x2, 0x34850, 0x20, 0xffbfc93c, 0xfbfe0bbc), at 0xfbea9728 [12] XPending(0x34110, 0x0, 0xfc2bec00, 0xfc2bec00, 0xfd21206c, 0x0), at 0xfbea9208 [13] _gdk_events_queue(0x3cb18, 0xfd8e9fe8, 0xfd8e9fd4, 0x23bf8, 0x0, 0xffbfca00), at 0xfd1c4b24 [14] gdk_event_dispatch(0x3f798, 0x3cb18, 0x3a4ec, 0xff2c02a0, 0x1000, 0xfd1ff244), at 0xfd1c4d8c [15] g_main_dispatch(0x3f7e0, 0xfc2bec00, 0x0, 0x0, 0xfffffffd, 0xffffffef), at 0xfc255ac8 [16] g_main_context_dispatch(0x3f7e0, 0x1, 0xeabd40, 0x1, 0xfc2bec00, 0x3f7e0), at 0xfc256ffc [17] g_main_context_iterate(0x1, 0x0, 0x1, 0x3f7e0, 0x3f7e8, 0x2), at 0xfc2574c8 [18] g_main_context_iteration(0x0, 0xfc2bec00, 0xfe4f9698, 0x3f7e0, 0x1, 0x0), at 0xfc2576d8 [19] GtkXLib::Yield(0x26ed8, 0x1, 0x0, 0x1, 0xfe4f30b0, 0xfd8e9fd4), at 0xfe49a954 [20] ImplYield(0xfd8dd75c, 0xfd8e9fe8, 0x1bc, 0x0, 0x1, 0x0), at 0xfd4e36dc [21] Application::Execute(0x1, 0xfd8e9fe8, 0xfd8e9fd4, 0xfd8dd75c, 0x1bc, 0x0), at 0xfd4dfe4c [22] desktop::Desktop::Main(0xffbfd34c, 0xfe6873f4, 0xf55c6c68, 0xf55c6c54, 0xffbfcf0c, 0x43cd48), at 0xfed182d4 [23] ImplSVMain(0xfed16004, 0xfd8e9fd4, 0x1, 0xfd8e9fe8, 0xfd8dd75c, 0x47574), at 0xfd4e6a94 [24] SVMain(0x0, 0x8002, 0xffbfd348, 0x2, 0x80000000, 0x40000000), at 0xfd4e6c70 [25] soffice_main(0x13c00, 0xfed998e8, 0xfffebfe5, 0x14000, 0xfffebfdd, 0x14000), at 0xfed44200 [26] main(0x7, 0xffbfd444, 0xffbfd464, 0x21400, 0xff3900c0, 0x0), at 0x10f88 (dbx) thread -blockedby t@5 Thread t@5 is blocked by: 0x00026728 (0x26728): thread mutex(locked) Lock owned by t@1 (dbx) where t@5 current thread: t@5 =>[1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xff3fa040, 0x1), at 0xff2c6df0 [2] mutex_lock_queue(0xfefa2200, 0x0, 0x26728, 0x0, 0x1c00, 0x1d3c), at 0xff2bf154 [3] osl_acquireMutex(0x0, 0x0, 0x0, 0x26728, 0x1, 0x71eb20), at 0xff01e43c [4] SalYieldMutex::acquire(0xfee04368, 0xfd8e9fd4, 0xfd8dd75c, 0xfee0436c, 0x3fd838, 0xfee04368), at 0xfab3a38c [5] SfxClipboardChangeListener::changedContents(0xf4120ee0, 0xf70a4c88, 0xfe49bdd4, 0xfe4f96bc, 0xf70af38c, 0xa704), at 0xf6e39c08 [6] x11::X11Clipboard::fireChangedContentsEvent(0xf413476c, 0xfaac4e88, 0xf547be40, 0xfab7e18c, 0xe70808, 0xe70828), at 0xfaac5b48 [7] x11::SelectionManager::run(0xf5aa0820, 0xe706b8, 0x10, 0xf547bee0, 0xf547bed8, 0xf547beec), at 0xfaad5d08 [8] osl_thread_start_Impl(0x726748, 0x726758, 0x18, 0xf547bf80, 0xff01ee28, 0xfaac7408), at 0xff01f09c (dbx) thread -blockedby t@30 Thread t@30 is blocked by: 0x00026728 (0x26728): thread mutex(locked) Lock owned by t@1 (dbx) where t@30 current thread: t@30 =>[1] __lwp_park(0x4, 0x0, 0x0, 0x0, 0xff3fa050, 0x1), at 0xff2c6df0 [2] mutex_lock_queue(0xfefa2a00, 0x0, 0x26728, 0x0, 0x1c00, 0x1d3c), at 0xff2bf154 [3] osl_acquireMutex(0x0, 0x1, 0xf257ba2c, 0x26728, 0x1, 0xfffc00), at 0xff01e43c [4] SalYieldMutex::acquire(0xfee04368, 0xfe4f96bc, 0xf404a298, 0x14270, 0x14000, 0xfee04368), at 0xfab3a38c [5] SvxShape::setSize(0xf1c2b744, 0xf1c72388, 0x4a0758, 0x7, 0x8, 0xf4036028), at 0xf3d86db0 [6] callVirtualMethod(0xf1c2b760, 0x7, 0x0, 0x0, 0xf257ba80, 0x2), at 0xfaa07238 [7] __unnamed_CHEEKn2fPMUt2::cpp_call(0xe2d568, 0x8, 0xf257bbec, 0x0, 0xdd9e60, 0xf257ba74), at 0xfaa03188 [8] bridges::cpp_uno::shared::unoInterfaceProxyDispatch(0xe2d568, 0xb05730, 0x0, 0xf257bbe8, 0xf257bc34, 0x19), at 0xfaa036ec [9] thisDispatch(0xeab9b0, 0xf257bc38, 0xf1c72370, 0x1, 0xf257bc08, 0xf257bbf0), at 0xf1f69c34 [10] bridges_urp::ServerMultiJob::execute(0xeac2c8, 0x2dc00, 0x0, 0xf1f6971c, 0xf1f68ae4, 0xf1f82b48), at 0xf1f5c91c [11] doit(0xeac2c8, 0x10, 0x2, 0xf1f5a678, 0x1, 0x0), at 0xf1f5a67c [12] cppu_threadpool::JobQueue::enter(0xf1f5a678, 0x49cb40, 0xfaa68b08, 0xe6b638, 0x1, 0xfaa7a7e0), at 0xfaa5a0f8 [13] cppu_threadpool::ORequestThread::run(0xe36c38, 0x0, 0x0, 0x0, 0xfffefa16, 0x10400), at 0xfaa5ad0c [14] cppu_requestThreadWorker(0xe36c38, 0xf257bf90, 0xff343800, 0x0, 0xfefa2a00, 0x0), at 0xfaa5a614 [15] osl_thread_start_Impl(0xae98d8, 0xae98e8, 0x18, 0xf257bf80, 0xff01ee28, 0xfaa5a610), at 0xff01f09c both cases hang in XPendingEvent which is explicitly not a waitinng function; I could imaging that this happens if two threads worked on the same display connection. X11 is supposed to protect itself from such if XInitThreads is called early, which we do unless the environment variable SAL_NO_XINITTHREADS is set (which was invented as a workaround for the buggy solaris Xlib implementation which was prone to deadlock itself since X11 does not use a recursive mutex). Do we by chance set this environment variable for this test ? target no reproducible Reset assignee on issues not touched by assignee in more than 2000 days. |