Download it now!
Bug 134112 - Python script freezes when access text field master in MailMerge event for the second time
Summary: Python script freezes when access text field master in MailMerge event for th...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
6.4.4.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Stephan Bergmann
URL:
Whiteboard: target:7.1.0 target:7.0.0.2 target:6.4.7
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-18 14:17 UTC by Oleg Shchelykalnov
Modified: 2020-09-23 11:35 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Python script for remote access (3.51 KB, text/plain)
2020-06-18 14:17 UTC, Oleg Shchelykalnov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oleg Shchelykalnov 2020-06-18 14:17:25 UTC
Created attachment 162170 [details]
Python script for remote access

I trying to provided example for MailMerge data substitution in python and caught issue. When I iterate over text field masters python script freezes on com.sun.star.text.fieldmaster.SetExpression.Table:

INFO:root:row = 1
DEBUG:root:Get text field masters
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.SetExpression.Illustration
DEBUG:root:Got text field master com.sun.star.text.fieldmaster.SetExpression.Illustration
INFO:root:Illustration
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.SetExpression.Table
DEBUG:root:Got text field master com.sun.star.text.fieldmaster.SetExpression.Table
(here freezes, Ctrl+C doesn't work)

OS: Ubuntu 18.04

pyuno.so library is from PPA 6.4.3-0ubuntu0.18.04.1 
Libreoffice remote server is from libreoffice-6-4~2020-06-15_02.11.02_LibreOfficeDev_6.4.6.0.0_Linux_x86-64_deb.tar.gz
Comment 1 Oleg Shchelykalnov 2020-06-18 14:29:38 UTC
Freeze happens even with empty text document.
Comment 2 Oleg Shchelykalnov 2020-06-18 14:36:09 UTC
Also I don't have same issue with similar Java code.
Comment 3 Oleg Shchelykalnov 2020-06-18 14:53:46 UTC
Looks like it doesn't depend on some text field master but for the second accessed on

I excluded builtin SetExpression and got same freeze for user fields in the document:

INFO:root:row = 1
DEBUG:root:Get text field masters
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.SetExpression.Illustration
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.SetExpression.Table
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.SetExpression.Text
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.SetExpression.Drawing
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.SetExpression.Figure
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.User.id_128C_6
DEBUG:root:Got text field master com.sun.star.text.fieldmaster.User.id_128C_6
INFO:root:Name = id_128C_6
DEBUG:root:textFieldMasterName = com.sun.star.text.fieldmaster.User.actualCapital
DEBUG:root:Got text field master com.sun.star.text.fieldmaster.User.actualCapital
Comment 4 Oleg Shchelykalnov 2020-06-18 15:44:26 UTC
I suppose it could be caught with tests:

diff --git a/sw/qa/python/xtextfieldssupplier.py b/sw/qa/python/xtextfieldssupplier.py
index ab1e96f89..f99b0fc85 100755
--- a/sw/qa/python/xtextfieldssupplier.py
+++ b/sw/qa/python/xtextfieldssupplier.py
@@ -69,8 +69,11 @@ class TestXTextFieldsSupplier(unittest.TestCase):
         for masterName in masterNames:
             self.assertTrue(xFieldMasters.hasByName(masterName),
                             "TextFieldMaster has no element " + masterName)
-            self.assertIsNotNone(xFieldMasters.getByName(masterName),
+            master = xFieldMasters.getByName(masterName)
+            self.assertIsNotNone(master,
                                  "can't get " + masterName + " from TextFieldMaster")
+            self.assertIsNotNone(master.getPropertyValue("Name"),
+                                 "can't get Name property from TextFieldMaster " + masterName)

         # Ensure that invalid elements are not accessible
         invalidMasterName = "com.sun.star.text.fieldmaster.SetExpression.NoSuchMaster"
Comment 5 Oleg Shchelykalnov 2020-06-19 09:54:51 UTC
I've tried to test it with Jenkins and test still passed.

Also I tried to access to the text field masters without MailMerge and didn't catch same freeze so I think it related to MailMerge or callback's to client's python code.
Comment 6 Stephan Bergmann 2020-06-22 09:37:27 UTC
Reproducer with attachment 162170 [details] from comment 0 as 162170.py:

mkdir /tmp/output
cp .../test3.odt /tmp # some empty Writer document
instdir/program/soffice '--accept=socket,host=localhost,port=8989;urp' &
instdir/program/python 162170.py

The python.bin process is waiting at

> Traceback (most recent call first):
>   File "162170.py", line 52, in notifyMailMergeEvent
>     logging.info("Name = %s" % textFieldMaster.getPropertyValue("Name"))
>   File "162170.py", line 122, in <module>
>     mailMerge.execute([])

while the soffice.bin process is deadlocked between

> Thread 32 (Thread 0x7f88eb7fe700 (LWP 219536)):
> #0  __lll_lock_wait (futex=futex@entry=0x1773360, private=0) at /usr/src/debug/glibc-2.31-17-gab029a2801/nptl/lowlevellock.c:52
> #1  0x00007f898af03ee1 in __GI___pthread_mutex_lock (mutex=0x1773360) at /usr/src/debug/glibc-2.31-17-gab029a2801/nptl/pthread_mutex_lock.c:115
> #2  0x00007f898b82efb9 in osl_acquireMutex(oslMutex) (pMutex=0x1773360) at sal/osl/unx/mutex.cxx:100
> #3  0x00007f898a3e1e88 in osl::Mutex::acquire() (this=0x1773338) at include/osl/mutex.hxx:57
> #4  0x00007f898a54c0f9 in comphelper::SolarMutex::doAcquire(unsigned int) (this=0x1773330, nLockCount=1) at comphelper/source/misc/solarmutex.cxx:56
> #5  0x00007f893e5a8c05 in comphelper::SolarMutex::acquire(unsigned int) (this=0x1773330, nLockCount=1) at include/comphelper/solarmutex.hxx:86
> #6  0x00007f893e5a8ba8 in osl::Guard<comphelper::SolarMutex>::Guard(comphelper::SolarMutex&) (this=0x7f88eb7fb040, t=...) at include/osl/mutex.hxx:135
> #7  0x00007f893e5a8105 in SolarMutexGuard::SolarMutexGuard() (this=0x7f88eb7fb040) at include/vcl/svapp.hxx:1347
> #8  0x00007f893f447246 in sw::UnoImplPtrDeleter<SwXFieldMaster::Impl>::operator()(SwXFieldMaster::Impl*) (this=0x7f8941fe3c48, pUnoImpl=0x7f8941fddb20) at sw/inc/unobaseclass.hxx:92
> #9  0x00007f893f44154d in std::unique_ptr<SwXFieldMaster::Impl, sw::UnoImplPtrDeleter<SwXFieldMaster::Impl> >::~unique_ptr() (this=0x7f8941fe3c48) at /usr/include/c++/10/bits/unique_ptr.h:360
> #10 0x00007f893f42bb3b in SwXFieldMaster::~SwXFieldMaster() (this=0x7f8941fe3c00) at sw/source/core/unocore/unofield.cxx:539
> #11 0x00007f893f42bb6c in SwXFieldMaster::~SwXFieldMaster() (this=0x7f8941fe3c00) at sw/source/core/unocore/unofield.cxx:538
> #12 0x00007f898a0b5f33 in cppu::OWeakObject::release() (this=0x7f8941fe3c00) at cppuhelper/source/weak.cxx:233
> #13 0x00007f893f443f98 in cppu::WeakImplHelper<com::sun::star::beans::XPropertySet, com::sun::star::lang::XServiceInfo, com::sun::star::lang::XUnoTunnel, com::sun::star::lang::XComponent>::release() (this=0x7f8941fe3c00) at include/cppuhelper/implbase.hxx:115
> #14 0x00007f896d279100 in bridges::cpp_uno::shared::freeUnoInterfaceProxy(uno_ExtEnvironment*, void*) (pEnv=0x7f8948001440, pProxy=0x7f8941fe4210) at bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:41
> #15 0x00007f898a1a072a in (anonymous namespace)::s_stub_defenv_revokeInterface(__va_list_tag (*) [1]) (pParam=0x7f88eb7fb5a0) at cppu/source/uno/lbenv.cxx:367
> #16 0x00007f898a18de69 in s_environment_invoke_v(_uno_Environment*, _uno_Environment*, void (*)(__va_list_tag (*) [1]), __va_list_tag (*) [1]) (pCurrEnv=0x0, pTargetEnv=0x7f8948001440, pCallee=0x7f898a1a0350 <(anonymous namespace)::s_stub_defenv_revokeInterface(__va_list_tag (*) [1])>, pParam=0x7f88eb7fb5a0) at cppu/source/uno/EnvStack.cxx:296
> #17 0x00007f898a18dd77 in uno_Environment_invoke_v(uno_Environment*, uno_EnvCallee*, va_list*) (pTargetEnv=0x7f8948001440, pCallee=0x7f898a1a0350 <(anonymous namespace)::s_stub_defenv_revokeInterface(__va_list_tag (*) [1])>, pParam=0x7f88eb7fb5a0) at cppu/source/uno/EnvStack.cxx:315
> #18 0x00007f898a18e053 in uno_Environment_invoke(uno_Environment*, uno_EnvCallee*, ...) (pEnv=0x7f8948001440, pCallee=0x7f898a1a0350 <(anonymous namespace)::s_stub_defenv_revokeInterface(__va_list_tag (*) [1])>) at cppu/source/uno/EnvStack.cxx:324
> #19 0x00007f898a1989ea in (anonymous namespace)::defenv_revokeInterface(_uno_ExtEnvironment*, void*) (pEnv=0x7f8948001440, pInterface=0x7f8941fe4210) at cppu/source/uno/lbenv.cxx:421
> #20 0x00007f896d27926a in bridges::cpp_uno::shared::releaseProxy(uno_Interface*) (pUnoI=0x7f8941fe4210) at bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:77
> #21 0x00007f896c3499ee in com::sun::star::uno::UnoInterfaceReference::~UnoInterfaceReference() (this=0x7f88eb7fb8c0) at include/uno/dispatcher.hxx:103
> #22 0x00007f896c342965 in binaryurp::Bridge::releaseStub(rtl::OUString const&, com::sun::star::uno::TypeDescription const&) (this=0x7f8948000e30, oid="7f8941fe3c00;gcc3[0];7b7a363bd4da4289a493f35a168d4543", type=...) at binaryurp/source/bridge.cxx:512
> #23 0x00007f896c372e4e in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const (this=0x7f88d5473bd0, returnValue=0x7f88eb7fc220, outArguments=0x7f88eb7fc1e8) at binaryurp/source/incomingrequest.cxx:137
> #24 0x00007f896c372243 in binaryurp::IncomingRequest::execute() const (this=0x7f88d5473bd0) at binaryurp/source/incomingrequest.cxx:78
> #25 0x00007f896c39fdbd in request(void*) (pThreadSpecificData=0x7f88d5473bd0) at binaryurp/source/reader.cxx:85
> #26 0x00007f898a139a04 in cppu_threadpool::JobQueue::enter(void const*, bool) (this=0x7f88d539f8b0, nDisposeId=0x7f88d54faba0, bReturnWhenNoJob=true) at cppu/source/threadpool/jobqueue.cxx:100
> #27 0x00007f898a141907 in cppu_threadpool::ORequestThread::run() (this=0x7f88d54faba0) at cppu/source/threadpool/thread.cxx:165
> #28 0x00007f898a145d31 in threadFunc(void*) (param=0x7f88d54fabb0) at include/osl/thread.hxx:185
> #29 0x00007f898b8494ba in osl_thread_start_Impl(void*) (pData=0x7f88d53c59f0) at sal/osl/unx/thread.cxx:258
> #30 0x00007f898af01432 in start_thread (arg=<optimized out>) at /usr/src/debug/glibc-2.31-17-gab029a2801/nptl/pthread_create.c:477
> #31 0x00007f898b3809d3 in clone () at /usr/src/debug/glibc-2.31-17-gab029a2801/sysdeps/unix/sysv/linux/x86_64/clone.S:95

doing a remote call of XMailMergeListener::notifyMailMergeEvent with the SolarMutex locked and

> Thread 31 (Thread 0x7f8946080700 (LWP 219516)):
> #0  futex_wait_cancelable (private=0, expected=0, futex_word=0x7f88d54e3108) at /usr/src/debug/glibc-2.31-17-gab029a2801/sysdeps/nptl/futex-internal.h:183
> #1  __pthread_cond_wait_common (abstime=0x0, clockid=0, mutex=0x7f88d54e2fe0, cond=0x7f88d54e30e0) at /usr/src/debug/glibc-2.31-17-gab029a2801/nptl/pthread_cond_wait.c:508
> #2  __pthread_cond_wait (cond=0x7f88d54e30e0, mutex=0x7f88d54e2fe0) at /usr/src/debug/glibc-2.31-17-gab029a2801/nptl/pthread_cond_wait.c:638
> #3  0x00007f898b14d870 in __gthread_cond_wait (__mutex=<optimized out>, __cond=<optimized out>) at /usr/src/debug/gcc-10.1.1-1.fc32.x86_64/obj-x86_64-redhat-linux/x86_64-redhat-linux/libstdc++-v3/include/x86_64-redhat-linux/bits/gthr-default.h:865
> #4  std::condition_variable::wait(std::unique_lock<std::mutex>&) (this=<optimized out>, __lock=...) at /usr/src/debug/gcc-10.1.1-1.fc32.x86_64/libstdc++-v3/src/c++11/condition_variable.cc:53
> #5  0x00007f898a1398a6 in cppu_threadpool::JobQueue::enter(void const*, bool) (this=0x7f88d54e2fe0, nDisposeId=0x7f8948006f00, bReturnWhenNoJob=false) at cppu/source/threadpool/jobqueue.cxx:72
> #6  0x00007f898a14cd41 in cppu_threadpool::ThreadPool::enter(rtl::ByteSequence const&, void const*) (this=0x7f8948009080, aThreadId=..., nDisposeId=0x7f8948006f00) at cppu/source/threadpool/threadpool.cxx:312
> #7  0x00007f898a14d695 in uno_threadpool_enter(uno_ThreadPool, void**) (hPool=0x7f8948006f00, ppJob=0x7f894607a6d0) at cppu/source/threadpool/threadpool.cxx:416
> #8  0x00007f896c343614 in binaryurp::Bridge::makeCall(rtl::OUString const&, com::sun::star::uno::TypeDescription const&, bool, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> > const&, binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) (this=0x7f8948000e30, oid="22c94b0;uno[0];35974;f34d6a5b827a4bf4bb5fa09a2971a4fa", member=..., setter=false, inArguments=std::__debug::vector of length 1, capacity 1 = {...}, returnValue=0x7f894607a9d8, outArguments=0x7f894607a9a0) at binaryurp/source/bridge.cxx:604
> #9  0x00007f896c39ed11 in binaryurp::Proxy::do_dispatch_throw(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const (this=0x7f88d543f9e0, member=0x7f8941fe8f60, returnValue=0x7f894607b280, arguments=0x7f894607abf0, exception=0x7f894607ad28) at binaryurp/source/proxy.cxx:168
> #10 0x00007f896c39e4fb in binaryurp::Proxy::do_dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const (this=0x7f88d543f9e0, member=0x7f8941fe8f60, returnValue=0x7f894607b280, arguments=0x7f894607abf0, exception=0x7f894607ad28) at binaryurp/source/proxy.cxx:101
> #11 0x00007f896c39e497 in proxy_dispatchInterface(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) (pUnoI=0x7f88d543f9e0, pMemberType=0x7f8941fe8f60, pReturn=0x7f894607b280, pArgs=0x7f894607abf0, ppException=0x7f894607ad28) at binaryurp/source/proxy.cxx:60
> #12 0x00007f896d26304b in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, _typelib_TypeDescription const*, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void**, void**, void**, unsigned long*) (pThis=0x7f88d53b6f90, pMemberTypeDescr=0x7f8941fe8f60, pReturnTypeRef=0x1784dd0, nParams=1, pParams=0x7f8941fe1b60, gpreg=0x7f894607b2b0, fpreg=0x7f894607b2d0, ovrflw=0x7f894607b320, pRegisterReturn=0x7f894607b280) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:185
> #13 0x00007f896d2627c5 in cpp_vtable_call(sal_Int32, sal_Int32, void**, void**, void**, sal_uInt64*) (nFunctionIndex=3, nVtableOffset=0, gpreg=0x7f894607b2a0, fpreg=0x7f894607b2d0, ovrflw=0x7f894607b320, pRegisterReturn=0x7f894607b280) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:373
> #14 0x00007f896d28634a in privateSnippetExecutor () at instdir/program/libgcc3_uno.so
> #15 0x00007f893fdac8a1 in SwXMailMerge::LaunchMailMergeEvent(com::sun::star::text::MailMergeEvent const&) const (this=0x7f8940000aa0, rEvt=...) at sw/source/uibase/uno/unomailmerge.cxx:837
> #16 0x00007f893f9dfbf6 in SwDBManager::MergeMailFiles(SwWrtShell*, SwMergeDescriptor const&) (this=0x7f89400a50a0, pSourceShell=0x7f8895fd84d0, rMergeDescriptor=...) at sw/source/uibase/dbui/dbmgr.cxx:1476
> #17 0x00007f893f9db86b in SwDBManager::Merge(SwMergeDescriptor const&) (this=0x7f89400a50a0, rMergeDesc=...) at sw/source/uibase/dbui/dbmgr.cxx:544
> #18 0x00007f893fdababe in SwXMailMerge::execute(com::sun::star::uno::Sequence<com::sun::star::beans::NamedValue> const&) (this=0x7f8940000aa0, rArguments=empty uno::Sequence) at sw/source/uibase/uno/unomailmerge.cxx:792
> #19 0x00007f893fdac705 in non-virtual thunk to SwXMailMerge::execute(com::sun::star::uno::Sequence<com::sun::star::beans::NamedValue> const&) () at instdir/program/../program/libswlo.so
> #20 0x00007f896d276f35 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) (pThis=0x7f8940000ac8, nVtableIndex=3, pRegisterReturn=0x7f894607d3e0, pReturnTypeRef=0x17778a0, bSimpleReturn=false, pStack=0x7f894607d400, nStack=0, pGPR=0x7f894607d720, pFPR=0x7f894607d6e0) at bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
> #21 0x00007f896d275afe in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, _typelib_TypeDescriptionReference*, int, _typelib_MethodParameter*, void*, void**, _uno_Any**) (pThis=0x7f8941e086f0, aVtableSlot=..., pReturnTypeRef=0x17778a0, nParams=1, pParams=0x7f893ab0b750, pUnoReturn=0x70d7be0, pUnoArgs=0x7f8941e07980, ppUnoExc=0x7f894607dc58) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233
> #22 0x00007f896d275235 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) (pUnoI=0x7f8941e086f0, pMemberDescr=0x7f88d54f6e80, pReturn=0x70d7be0, pArgs=0x7f8941e07980, ppException=0x7f894607dc58) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:413
> #23 0x00007f896c373b5e in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const (this=0x7f88d551f860, returnValue=0x7f894607e220, outArguments=0x7f894607e1e8) at binaryurp/source/incomingrequest.cxx:235
> #24 0x00007f896c372243 in binaryurp::IncomingRequest::execute() const (this=0x7f88d551f860) at binaryurp/source/incomingrequest.cxx:78
> #25 0x00007f896c39fdbd in request(void*) (pThreadSpecificData=0x7f88d551f860) at binaryurp/source/reader.cxx:85
> #26 0x00007f898a139a04 in cppu_threadpool::JobQueue::enter(void const*, bool) (this=0x7f88d54e2fe0, nDisposeId=0x7f88d54f0f30, bReturnWhenNoJob=true) at cppu/source/threadpool/jobqueue.cxx:100
> #27 0x00007f898a141907 in cppu_threadpool::ORequestThread::run() (this=0x7f88d54f0f30) at cppu/source/threadpool/thread.cxx:165
> #28 0x00007f898a145d31 in threadFunc(void*) (param=0x7f88d54f0f40) at include/osl/thread.hxx:185
> #29 0x00007f898b8494ba in osl_thread_start_Impl(void*) (pData=0x7f88d539f1f0) at sal/osl/unx/thread.cxx:258
> #30 0x00007f898af01432 in start_thread (arg=<optimized out>) at /usr/src/debug/glibc-2.31-17-gab029a2801/nptl/pthread_create.c:477
> #31 0x00007f898b3809d3 in clone () at /usr/src/debug/glibc-2.31-17-gab029a2801/sysdeps/unix/sysv/linux/x86_64/clone.S:95

servicing an asynchronous remote release request, apparently on the same logical UNO thread, and trying to acquire the SolarMutex.
Comment 7 Commit Notification 2020-06-22 12:18:35 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/e7cd344cd0d2cc197e3dfd47c262a13631ccda83

tdf#134112 Don't call UNO listeners with SolarMutex locked

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Oleg Shchelykalnov 2020-06-22 17:18:19 UTC
Could this fix be backported to previous other release branches?
Comment 9 Stephan Bergmann 2020-06-23 06:37:04 UTC
(In reply to Oleg Shchelykalnov from comment #8)
> Could this fix be backported to previous other release branches?

Those SolarMutexReleaser hacks always carry a certain risk of causing crashes or deadlocks.  If there is no compelling reason for a specific backport, I would prefer not to do a general backport to current release branches.
Comment 10 Commit Notification 2020-07-02 08:47:18 UTC
Oleg Schelykalnov committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/076fdbdb912809614a48377ab4b86cd2e2cb228f

tdf#134112 sw: Test access of text field master object

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Commit Notification 2020-07-10 10:07:20 UTC
Oleg Schelykalnov committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/062ef78e86534c19c66e968a137b653b02e707d3

tdf#134112 sw: Test access of text field master object

It will be available in 7.0.0.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2020-09-23 11:35:32 UTC
Oleg Schelykalnov committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/def6e51cd56814aad3cbb8c1035da71c47927854

tdf#134112 sw: Test access of text field master object

It will be available in 6.4.7.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.