Linux-RHEL6-x86_64@14-with-check tinderbox once failed during toolkit_unoapi test with > #0 0x00000030b5e09220 in pthread_mutex_lock () from /lib64/libpthread.so.0 > #1 0x00007f02ac11b618 in osl_acquireMutex (Mutex=0x9999999999999999) at /home/tinderbox/master/sal/osl/unx/mutex.c:114 > #2 0x00007f02918fbfe7 in osl::Mutex::acquire (this=0x39cbb50) at /home/tinderbox/master/solver/unxlngx6/inc/osl/mutex.hxx:58 > #3 0x00007f02918ff4f2 in osl::Guard<osl::Mutex>::Guard (this=0x7f028adebe40, t=...) at /home/tinderbox/master/solver/unxlngx6/inc/osl/mutex.hxx:144 > #4 0x00007f0291920966 in SwAccessibleMap::RemoveContext (this=0x39cbb40, pFrm=0x35520f0) at /home/tinderbox/master/sw/source/core/access/accmap.cxx:1553 > #5 0x00007f0291908c9a in SwAccessibleContext::RemoveFrmFromAccessibleMap (this=0x39cf558) at /home/tinderbox/master/sw/source/core/access/acccontext.cxx:1429 > #6 0x00007f0291903c1c in SwAccessibleContext::~SwAccessibleContext (this=0x39cf558, __in_chrg=<value optimized out>) at /home/tinderbox/master/sw/source/core/access/acccontext.cxx:532 > #7 0x00007f029193df92 in SwAccessibleParagraph::~SwAccessibleParagraph (this=0x39cf530, __in_chrg=<value optimized out>) at /home/tinderbox/master/sw/source/core/access/accpara.cxx:500 > #8 0x00007f029193e014 in ::~SwAccessibleParagraph (this=0x39cf530, __in_chrg=<value optimized out>) at /home/tinderbox/master/sw/source/core/access/accpara.cxx:500 > #9 0x00007f02ab3c88ac in cppu::OWeakObject::release (this=0x39cf558) at /home/tinderbox/master/cppuhelper/source/weak.cxx:204 > #10 0x00007f02918ff128 in cppu::WeakImplHelper5<com::sun::star::accessibility::XAccessible, com::sun::star::accessibility::XAccessibleContext, com::sun::star::accessibility::XAccessibleComponent, com::sun::star::accessibility::XAccessibleEventBroadcaster, com::sun::star::lang::XServiceInfo>::release (this=0x39cf558) at /home/tinderbox/master/solver/unxlngx6/inc/cppuhelper/implbase5.hxx:110 > #11 0x00007f029194bfaa in SwAccessibleParagraph::release (this=0x39cf530) at /home/tinderbox/master/sw/source/core/access/accpara.hxx:296 > #12 0x00007f029aa7904d in bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x324f6e0, pProxy=0x39cc050) at /home/tinderbox/master/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:43 > #13 0x00007f02ab68c5c0 in (anonymous namespace)::s_stub_defenv_revokeInterface (pParam=0x7f028adec240) at /home/tinderbox/master/cppu/source/uno/lbenv.cxx:391 > #14 0x00007f02ab687fad in s_environment_invoke_v (pCurrEnv=0x0, pTargetEnv=0x324f6e0, pCallee=0x7f02ab68c2b6 <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>, pParam=0x7f028adec240) at /home/tinderbox/master/cppu/source/uno/EnvStack.cxx:287 > #15 0x00007f02ab688053 in uno_Environment_invoke_v (pTargetEnv=0x324f6e0, pCallee=0x7f02ab68c2b6 <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>, pParam=0x7f028adec240) at /home/tinderbox/master/cppu/source/uno/EnvStack.cxx:306 > #16 0x00007f02ab68813e in uno_Environment_invoke (pEnv=0x324f6e0, pCallee=0x7f02ab68c2b6 <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>) at /home/tinderbox/master/cppu/source/uno/EnvStack.cxx:315 > #17 0x00007f02ab68c977 in (anonymous namespace)::defenv_revokeInterface (pEnv=0x324f6e0, pInterface=0x3966b30) at /home/tinderbox/master/cppu/source/uno/lbenv.cxx:447 > #18 0x00007f029aa7917b in bridges::cpp_uno::shared::releaseProxy (pUnoI=0x3966b30) at /home/tinderbox/master/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:85 > #19 0x00007f0297ad66d9 in com::sun::star::uno::UnoInterfaceReference::~UnoInterfaceReference (this=0x7f028adec430, __in_chrg=<value optimized out>) at /home/tinderbox/master/solver/unxlngx6/inc/uno/dispatcher.hxx:88 > #20 0x00007f0297ad07af in binaryurp::Bridge::releaseStub (this=0x324f510, oid=..., type=...) at /home/tinderbox/master/binaryurp/source/bridge.cxx:525 > #21 0x00007f0297aeb79a in binaryurp::IncomingRequest::execute_throw (this=0x39c8ae0, returnValue=0x7f028adecb00, outArguments=0x7f028adeca70) at /home/tinderbox/master/binaryurp/source/incomingrequest.cxx:139 > #22 0x00007f0297aeae63 in binaryurp::IncomingRequest::execute (this=0x39c8ae0) at /home/tinderbox/master/binaryurp/source/incomingrequest.cxx:74 > #23 0x00007f0297b05c1a in binaryurp::(anonymous namespace)::request (pThreadSpecificData=0x39c8ae0) at /home/tinderbox/master/binaryurp/source/reader.cxx:87 > #24 0x00007f02ab655178 in cppu_threadpool::JobQueue::enter (this=0x390e5d0, nDisposeId=62443856, bReturnWhenNoJob=1 '\001') at /home/tinderbox/master/cppu/source/threadpool/jobqueue.cxx:115 > #25 0x00007f02ab659439 in cppu_threadpool::ORequestThread::run (this=0x3b8d150) at /home/tinderbox/master/cppu/source/threadpool/thread.cxx:173 > #26 0x00007f02ab659c99 in osl::threadFunc (param=0x3b8d160) at /home/tinderbox/master/solver/unxlngx6/inc/osl/thread.hxx:187 > #27 0x00007f02ac12630b in osl_thread_start_Impl (pData=0x3a6d090) at /home/tinderbox/master/sal/osl/unx/thread.c:252 > #28 0x00000030b5e07851 in start_thread () from /lib64/libpthread.so.0 > #29 0x00000030b5ae890d in clone () from /lib64/libc.so.6 (while main thread was harmlessly blocking on vcl::SolarMutexObject::acquire during Application::Yield). SwAccessibleParagraph -> SwAccessibleContext is a UNO object with a SwAccessibleMap * pMap member. However, lifetime of that SwAccessibleMap appears to be controlled by SwViewImp (pAccMap member, created in SwViewImp::CreateAccessibleMap, destroyed in ~SwViewImp) while lifetime of SwViewImp appears to be unrelated to lifetime of SwAccessibleParagraph UNO object.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) Thank you for your help! -- The LibreOffice QA Team
it's possible this is "fixed" by: commit 296e8b597c141b6b54cbf943871d6a6820c1779d Author: Michael Stahl <mstahl@redhat.com> AuthorDate: Thu Dec 18 21:52:51 2014 +0100 fdo#87199: sw: fix root cause of a11y crash when merging cells ... which should dispose (and thereby remove from the SwAccessibleMap) more SwAccessible instances but it's hard to know for sure...
...so tentatively close as WORKSFORME for now; doesn't help much to have this issue remain open for years anyway
unfortunately still happens on current master, again in toolkit_unoapi, a mail from "Linux-F19-x86_64@14-with-check" has the same stack.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.0) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-02-21
yes unfortunately this still happens
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d0b09f41efe938e94a84e783c9ff5742edcbfba8 sw: related: tdf#58624 convert to assert() in ~SwAccessibleMap() It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
mystery - the SwAccessibleMap contains thread-safe WeakReferences to SwAccessibles, ~SwAccessibleMap actually resets the back-pointer in all SwAccessibles to null, *and* the ~SwAccessibleContext locks the SolarMutex, so it's a complete mystery how it can happen that ~SwAccessibleContext sees a non-null m_pMap pointing to dead map
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.5 or 5.3.0 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170306
finally tracked it down -> fixed on master
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c2229dcab143925c6ad390e0735e2d98c3eecca tdf#58624 sw: fix ~SwAccessibleContext() use-after-free race It will be available in 5.4.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=aba392d1a07b8b0d40583d7e893a409cf96f1725&h=libreoffice-5-3 tdf#58624 sw: fix ~SwAccessibleContext() use-after-free race It will be available in 5.3.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.