As
commit a545badd65
Author: Stephan Bergmann <sbergman@redhat.com>
Date: Thu Feb 16 18:15:04 2012 +0100
Work around macro redefinition warning
already did for pyuno/source/module/pyuno_dlopenwrapper.c ,
also include the <Python.h> header first
in more pyuno source files.
Quoting from the Python/C API reference manual about include
files [1]:
> Note: Since Python may define some pre-processor definitions
> which affect the standard headers on some systems, you must
> include Python.h before any standard headers are included.
This avoids build errors like the following otherwise seen
on Debian testing after a glibc update from 2.42-17 to 2.43-3:
In file included from /home/michi/development/git/libreoffice/pyuno/source/module/pyuno_struct.cxx:28:
In file included from /home/michi/development/git/libreoffice/pyuno/source/module/pyuno_impl.hxx:26:
In file included from /home/michi/development/git/libreoffice/workdir/UnpackedTarball/python3/Include/Python.h:14:
/home/michi/development/git/libreoffice/workdir/UnpackedTarball/python3/pyconfig.h:1985:9: error: '_POSIX_C_SOURCE' macro redefined [-Werror,-Wmacro-redefined]
1985 | #define _POSIX_C_SOURCE 200809L
| ^
/usr/include/features.h:319:10: note: previous definition is here
319 | # define _POSIX_C_SOURCE 202405L
| ^
[1] https://docs.python.org/3/c-api/intro.html#include-files
Change-Id: I4ae90cfc9b92b559181d3884cdc8d51ee11f922d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209871
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
If an object implements XInvocation then the Invocation service will
directly return the object instead of creating its own invocation
wrapper. In that case the object isn’t guaranteed to also implement
XInvocation2. Previously, this was making pyuno just throw an exception
whenever it encounters one of these objects.
The only case where XInvocation2 is actually used is the implementation
of the __dir__ method. I don’t think this method is used very often so
it’s probably OK to just make it return an empty list if XInvocation2
isn’t supported. That way we can just store a reference to XInvocation
instead of XInvocation2.
This change makes it possible to use objects that implement XInvocation
from Python, for example ooo.vba.excel.Application.
Change-Id: I822c4ffa760f52d6488b9c1009435d059fc19fdd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209086
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Many implementations of XInvocation for internal objects return null for
the getIntrospection method. In pyuno this method is only used in one
place to try and catch the case where the wrapped object is already a
PyUNO adapter. Let’s check for null in that case and assume the object
isn’t an adapter so that it won’t crash when handling objects that
implement XInvocation.
Change-Id: I26576a1a9fec92c679373d9ab47824d992065041
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209085
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Tested-by: Jenkins
PyUNOStruct_dir is an almost exact copy of PyUNO_dir. This deletes the
first one and makes the struct code instead directly use PyUNO_dir. The
object version has the small advantage that it pre-allocates the Python
list to the right size so the struct code can now take advantage of that
too.
This will make it easier to modify the dir implementation for both use
cases in a later patch.
Change-Id: I7ebe2e6d547fd27c228842effd534e8d71d634ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/209084
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
When any2PyObject is given an interface which is actually an adapter for
a Python object, it now returns the original Python object instead of a
new wrapper for the object. This means that calling methods on the
returned object will be faster because they won’t involve UNO bridging.
It also means that Python implementations of UNO interfaces can detect
when they are given Python objects as a parameter and take advantage of
any internal private data attached to the object.
Change-Id: Ie13d0612f48e70973bd523e68710ec33a7875a16
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207507
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
That function was added in Python 3.9. Even though the LibreOffice
README says the baseline is 3.11, the configure script actually lets you
build with 3.3. I tested with Python 3.5 and it does work apart from
that function call and the fact that desktop-translate.py is using
f-strings. The call to PyObject_CallOneArg was added in the patch below
after the 26.2 branch point so it hasn’t been battle-tested in a release
version yet. Seeing as it’s easy to use an alternative let’s do that in
case someone is using a really old version of Python with pyuno for some
reason.
commit 45d2412c78
Author: Neil Roberts <bpeeluk@yahoo.co.uk>
Date: Wed Feb 11 16:40:48 2026 +0100
tdf#171122 pyuno: Add class getter methods for singletons
Change-Id: Ic6f7cf8d0005f59e8cbfd1f9703d393b7e30dabe
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206333
Tested-by: Jenkins
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
Building with clang 21.1.8 and --enable-werror fails because glibc 2.43
adopted the C23 behavior for strrchr(), where it now returns const char*
when its input is const char*. Assigning the result to a plain char*
discards the const qualifier, which clang rejects as an error since the flag is passed.
Change-Id: Ib8eecd603bedb4a69c8f7bd93e49f01e8eba28d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199863
Tested-by: Jenkins
Reviewed-by: Neil Roberts <bpeeluk@yahoo.co.uk>
Makes it possible to import the name of a singleton into a Python script
as a class and then retrieve it with a getter method. Eg, instead of:
desktop = ctx.getValueByName(
"/singletons/com.sun.star.frame.theDesktop")
you can now do:
from com.sun.star.frame import theDesktop
desktop = theDesktop.get(ctx)
Change-Id: I009bd2e890cde52aa6273e462621157fc1f63661
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199219
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
This makes it so that services can be imported in Python with code like
this:
from com.sun.star.resource import StringResourceWithLocation
And then an instance of the service can be constructed using any of its
constructors as a class method like this:
res = StringResourceWithLocation.create(ctx, root_url, True, locale,
dlg, '', None)
This has the advantage that the number of arguments can be checked
properly and a more useful error message can be reported if they are not
correct. Because pyuno knows what types the arguments are supposed to
be, it can also do a better job of coercing them to the right ones. For
example in the example above it is possible to pass None for an
interface argument even though that normally represents the void type.
This idea evolved out of the discussion for tdf#169229.
Change-Id: I9b542178f1c101d58dcbbd241d4ecbc9fe38bc2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199104
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Previously when creating a callable object for an attribute on an
object (ie, a method), it would mark it with a special mode to disallow
passing a pyuno.Any as an argument. There doesn’t seem to be a good
reason to do this and it makes it difficult to use an explicit type when
calling a method that can take an Any. This patch instead just removes
the mode parameter from pyobject2Any entirely.
The example in the bug report is trying to call
createInstanceWithArgumentsAndContext which takes a Sequence of Anys as
an argument. Without this patch it is difficult to pass a null interface
as one of the arguments.
Change-Id: I8756bdc2821ebf247ff67a66f071263ac00e3890
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195452
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
...for cases where one operand is a PyUNO Adapter of the other (i.e., one
operand is a Python object that got passed out and back in again, and the other
operand is that same Python object). This fixes the second "TODO" from
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest".
Change-Id: I0fc938db5c464ed56adee3b428537925fff0fc81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195392
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
That
> // the exception base functions want to have an "args" tuple,
> // which contains the message
code is there ever since e80bdbafeb "initial
checkin for the pyuno-0.9.2 release" for reasons that are not clear to me, but
at least in the "TODO" scenarios from 3320b5fe2e
"Add exhaustive testing of PyUNO type mapping based on embindtest" and
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest" (which are hereby fixed), that
PyObject_SetAttrString would cause a Python exception, cf.
> info:pyuno.runtime:1489432:1489432:pyuno/source/module/pyuno_runtime.cxx:533: setting exception args raised Python exception <class 'AttributeError'>: AttributeError('args')
so at least catch that. (And maybe that code is obsolete anyway it would make
even more sense to drop it altogether.)
Change-Id: Ic651d106f34e0b316cba59ae66d2402b8f86b0f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195340
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(Stumbled over this when while preparing
1e2e9a20a4 "More exhaustive testing of PyUNO type
mapping based on embindtest" I accidentally forgot the
> from org.libreoffice.embindtest import Exception
in pyuno/qa/pytests/embindtest.py and thus PythonTest_pyuno_pytests_embindtest
would SIGABRT with
> sal/rtl/strtmpl.hxx:122: auto rtl::str::Copy(sal_Unicode *, const char *, sal_Int32)::(anonymous class)::operator()(char) const: Assertion `rtl::isAscii(static_cast<unsigned char>(c))' failed.
from pyuno::lcl_ExceptionMessage (with reprString being "('error', None,
-123456, 100.5, 'hä')") while trying to report
> uno.com.sun.star.uno.RuntimeException: Couldn't convert ('error', None, -123456, 100.5, 'hä') to a UNO type; caught exception: <class 'AttributeError'>: 'Exception' object has no attribute 'getTypes', traceback follows
.)
Change-Id: I4581061dbfa190266fef98dc670a058d6c98eaaf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195304
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
...by implementing all the getAny... variants that were left out of
5f05929fd1498e418618d7570192877055de2c80 "Add exhaustive testing of PyUNO type
mapping based on embindtest".
Which revealed that the code in Adapter::invoke (in
pyuno/source/module/pyuno_adapter.cxx) was apparently broken, and would cause
the C++ call in doExecuteTest (in unotest/source/embindtest/embindtest.cxx) of
the Python
> def getAnyByte(self):
> return uno.Any('byte', -12)
(in pyuno/qa/pytests/embindtest.py) to fail with a nonsensical
> uno.com.sun.star.uno.RuntimeException: uno.Any instance not accepted during method call, use uno.invoke instead at pyuno/source/module/pyuno_runtime.cxx:785 at stoc/source/invocation_adapterfactory/iafactory.cxx:203
In addition, there's two new places marked with TODO comments:
For one, executing C++
> bool const ok = test->isAnyException(val);
would cause an odd
> python.bin: Objects/typeobject.c:4745: PyObject *_PyType_Lookup(PyTypeObject *, PyObject *): Assertion `!PyErr_Occurred()' failed.
failure that needs further investigation.
And for another, executing Python
> return value == self
would always return false. It appears that PyUNO_cmp (in
pyuno/source/module/pyuno.cxx isn't yet prepared to be called with `that` being
a native Python UNO-implemenation object (`class Test(unohelper.Base, XTest)`)
instead of a proxy for a binary/C++ UNO object.
Change-Id: I0289e1f5ee6dab53b589af783c0c53302989394c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195287
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
As Clang supports that warning now too, lots of occurrences have meanwhile been
cleaned up for good (0c29c417ef "Avoid
-Werror,-Wcast-function-type-mismatch", 1344e6261a
"Avoid -Werror,-Wcast-function-type-mismatch",
85a2bb9f52 "Avoid
-Werror,-Wcast-function-type-mismatch", etc.), so
ce99754e9b "Globally disable -Wcast-function-type
new with upcoming GCC 8" in solenv/gbuild/platform/com_GCC_defs.mk should no
longer be necessary.
One remaining issue I encountered was dae7304df6
"Silence Clang 19 trunk -Werror,-Wcast-function-type-mismatch", where GCC needs
a different way for silencing the warnings in pyuno/source/module/ than had been
used there for Clang.
Change-Id: I5d0404b957d798114051209c31e022a898cf91f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173623
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
The problem was that running UITest_xmlsecurity_gpg changed the files in
test/signing-keys/ ... prevent that by copying the directory in that
test, which is more complicated than initially expected.
Change-Id: Ie3be922e0b2e9dae49f9a70e35ad5270c90b4fc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171322
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
...which caused e.g. UITest_writer_tests3 to occasionally hang with the
python.bin process thread 1 at
> File "sw/qa/uitest/writer_tests3/insertPageFooter.py", line 30, in delete_footer
[...]
i.e.,
> #4 ___pthread_cond_wait at /usr/src/debug/glibc-2.35-4.fc36.x86_64/nptl/pthread_cond_wait.c:618
> #5 0x00007ff9d6ad9c43 in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:72
> #6 0x00007ff9d6ae8e79 in cppu_threadpool::ThreadPool::enter(rtl::ByteSequence const&, void const*) at cppu/source/threadpool/threadpool.cxx:303
> #7 0x00007ff9d6ae9278 in uno_threadpool_enter(uno_ThreadPool, void**) at cppu/source/threadpool/threadpool.cxx:407
> #8 0x00007ff9c7d016eb in binaryurp::Bridge::makeCall(rtl::OUString const&, com::sun::star::uno::TypeDescription const&, bool, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >&&, binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) at binaryurp/source/bridge.cxx:604
> #9 0x00007ff9c7d322fc in binaryurp::Proxy::do_dispatch_throw(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:168
> #10 0x00007ff9c7d338cb in binaryurp::Proxy::do_dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:101
> #11 0x00007ff9d63222e0 in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, typelib_TypeDescription const*, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:191
> #12 0x00007ff9d6322b59 in cpp_vtable_call(sal_Int32, sal_Int32, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:389
> #13 0x00007ff9d63336ca in privateSnippetExecutor at instdir/program/libgcc3_uno.so
> #14 0x00007ff9d6241f38 in (anonymous namespace)::ImplIntrospectionAccess::hasByName(rtl::OUString const&) at stoc/source/inspect/introspection.cxx:1114
> #15 0x00007ff9d6b856b2 in pyuno::PyUNO_getattr(PyObject*, char*) at pyuno/source/module/pyuno.cxx:1392
[...]
doing a remote call to soffice.bin with GIL locked, and thread 4 at
> #6 0x00007ff9e51efa28 in take_gil at workdir/UnpackedTarball/python3/Python/ceval_gil.h:207
> #7 0x00007ff9e51f00d3 in PyEval_AcquireThread at workdir/UnpackedTarball/python3/Python/ceval.c:316
> #8 0x00007ff9d6b9b1e8 in pyuno::Adapter::invoke(rtl::OUString const&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&, com::sun::star::uno::Sequence<short>&, com::sun::star::uno::Sequence<com::sun::star::uno::Any>&) at pyuno/source/module/pyuno_adapter.cxx:181
> #9 0x00007ff9d632b3e4 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) at bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
> #10 0x00007ff9d632a4f1 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233
> #11 0x00007ff9d632a9e6 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:413
> #12 0x00007ff9d621384a in stoc_invadp::(anonymous namespace)::AdapterImpl::invoke at stoc/source/invocation_adapterfactory/iafactory.cxx:457
> #13 stoc_invadp::adapter_dispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) at stoc/source/invocation_adapterfactory/iafactory.cxx:605
> #14 0x00007ff9c7d1a7db in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const at include/typelib/typedescription.hxx:155
> #15 0x00007ff9c7d1d65f in binaryurp::IncomingRequest::execute() const at binaryurp/source/incomingrequest.cxx:78
> #16 0x00007ff9c7d33ad3 in binaryurp::(anonymous namespace)::request(void*) at ~/gcc/trunk/inst/include/c++/12.0.1/bits/unique_ptr.h:172
> #17 0x00007ff9d6ad9e1b in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:100
> #18 0x00007ff9d6adbb80 in cppu_threadpool::ORequestThread::run() at cppu/source/threadpool/thread.cxx:164
[...]
processing an unrelated incoming call from soffice.bin and blocked trying to
lock the GIL. (The reason that thread 1 doesn't make progress is that the
soffice.bin process is also blocking with thread 6 at
> #8 osl::Guard<comphelper::SolarMutex>::Guard(comphelper::SolarMutex&) at include/osl/mutex.hxx:142
> #9 SolarMutexGuard::SolarMutexGuard() at include/vcl/svapp.hxx:1368
> #10 sw::(anonymous namespace)::XStyleFamily::hasByName(rtl::OUString const&) at sw/source/core/unocore/unostyle.cxx:923
> #11 0x00007f089d3d53e4 in gcc3::callVirtualMethod(void*, unsigned int, void*, _typelib_TypeDescriptionReference*, bool, unsigned long*, unsigned int, unsigned long*, double*) at bridges/source/cpp_uno/gcc3_linux_x86-64/callvirtualmethod.cxx:77
> #12 0x00007f089d3d44f1 in cpp_call(bridges::cpp_uno::shared::UnoInterfaceProxy*, bridges::cpp_uno::shared::VtableSlot, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:233
> #13 0x00007f089d3d49e6 in bridges::cpp_uno::shared::unoInterfaceProxyDispatch(uno_Interface*, typelib_TypeDescription const*, void*, void**, uno_Any**) at bridges/source/cpp_uno/gcc3_linux_x86-64/uno2cpp.cxx:413
> #14 0x00007f089c1be7db in binaryurp::IncomingRequest::execute_throw(binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) const at include/typelib/typedescription.hxx:155
> #15 0x00007f089c1c165f in binaryurp::IncomingRequest::execute() const at binaryurp/source/incomingrequest.cxx:78
> #16 0x00007f089c1d7ad3 in binaryurp::(anonymous namespace)::request(void*) at ~/gcc/trunk/inst/include/c++/12.0.1/bits/unique_ptr.h:172
> #17 0x00007f08a18ade1b in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:100
> #18 0x00007f08a18afb80 in cppu_threadpool::ORequestThread::run() at cppu/source/threadpool/thread.cxx:164
[...]
processing the incoming call from python.bin thread 1 and blocked trying to lock
the SolarMutex, while thread 1 at
> #4 ___pthread_cond_wait at /usr/src/debug/glibc-2.35-4.fc36.x86_64/nptl/pthread_cond_wait.c:618
> #5 0x00007f08a18adc43 in cppu_threadpool::JobQueue::enter(void const*, bool) at cppu/source/threadpool/jobqueue.cxx:72
> #6 0x00007f08a18bce79 in cppu_threadpool::ThreadPool::enter(rtl::ByteSequence const&, void const*) at cppu/source/threadpool/threadpool.cxx:303
> #7 0x00007f08a18bd278 in uno_threadpool_enter(uno_ThreadPool, void**) at cppu/source/threadpool/threadpool.cxx:407
> #8 0x00007f089c1a56eb in binaryurp::Bridge::makeCall(rtl::OUString const&, com::sun::star::uno::TypeDescription const&, bool, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >&&, binaryurp::BinaryAny*, std::__debug::vector<binaryurp::BinaryAny, std::allocator<binaryurp::BinaryAny> >*) at binaryurp/source/bridge.cxx:604
> #9 0x00007f089c1d62fc in binaryurp::Proxy::do_dispatch_throw(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:168
> #10 0x00007f089c1d78cb in binaryurp::Proxy::do_dispatch(_typelib_TypeDescription const*, void*, void**, _uno_Any**) const at binaryurp/source/proxy.cxx:101
> #11 0x00007f089d3cc2e0 in cpp2uno_call(bridges::cpp_uno::shared::CppInterfaceProxy*, typelib_TypeDescription const*, typelib_TypeDescriptionReference*, sal_Int32, typelib_MethodParameter*, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:191
> #12 0x00007f089d3ccb59 in cpp_vtable_call(sal_Int32, sal_Int32, void**, void**, void**, sal_uInt64*) at bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:389
> #13 0x00007f089d3dd6ca in privateSnippetExecutor at instdir/program/libgcc3_uno.so
> #14 0x00007f08a6b5d170 in operator() at sfx2/source/notify/globalevents.cxx:491
> #15 comphelper::OInterfaceContainerHelper4<com::sun::star::document::XDocumentEventListener>::forEach<(anonymous namespace)::SfxGlobalEvents_Impl::implts_notifyListener(const com::sun::star::document::DocumentEvent&)::<lambda(const com::sun::star::uno::Reference<com::sun::star::document::XDocumentEventListener>&)> > at include/comphelper/interfacecontainer4.hxx:285
> #16 at sfx2/source/notify/globalevents.cxx:488
> #17 0x00007f08a6b04c8b in (anonymous namespace)::NotifySingleListenerIgnoreRE<com::sun::star::document::XDocumentEventListener, com::sun::star::document::DocumentEvent>::operator() (listener=Python Exception <class 'gdb.error'>: Dwarf Error: Cannot find DIE at 0x0 referenced in module instdir/program/libmergedlo.so
> #18 comphelper::OInterfaceContainerHelper2::forEach<com::sun::star::document::XDocumentEventListener, at include/comphelper/interfacecontainer2.hxx:271
> #19 SfxBaseModel::postEvent_Impl(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::frame::XController2> const&, com::sun::star::uno::Any const&) at sfx2/source/doc/sfxbasemodel.cxx:3253
> #20 0x00007f08a6b066fe in SfxBaseModel::Notify(SfxBroadcaster&, SfxHint const&) at sfx2/source/doc/sfxbasemodel.cxx:2902
> #21 0x00007f08a6f15def in SfxBroadcaster::Broadcast(SfxHint const&) at svl/source/notify/SfxBroadcaster.cxx:39
> #22 0x00007f087d640650 in SwLayIdle::SwLayIdle(SwRootFrame*, SwViewShellImp*) at sw/source/core/layout/layact.cxx:2389
> #23 0x00007f087dc0832b in SwViewShell::LayoutIdle() at sw/source/core/view/viewsh.cxx:821
> #24 0x00007f087d2ba194 in sw::DocumentTimerManager::DoIdleJobs(Timer*) at sw/source/core/inc/rootfrm.hxx:206
> #25 0x00007f08a89fbd26 in Scheduler::CallbackTaskScheduling() at vcl/source/app/scheduler.cxx:472
> #26 0x00007f08a8ca8780 in SalTimer::CallCallback() at vcl/inc/saltimer.hxx:54
> #27 SvpSalInstance::CheckTimeout(bool) at vcl/headless/svpinst.cxx:212
> #28 0x00007f08a8ca99bd in SvpSalInstance::ImplYield(bool, bool) at vcl/headless/svpinst.cxx:452
> #29 0x00007f08a8ca9db1 in SvpSalInstance::DoYield(bool, bool) at vcl/headless/svpinst.cxx:524
> #30 0x00007f08a8a27d4c in ImplYield(bool, bool) at vcl/source/app/svapp.cxx:474
> #31 0x00007f08a8a28445 in Application::Execute() at vcl/source/app/svapp.cxx:452
[...]
is doing the remote call to python.bin thread 4 with the SolarMutex erroneously
locked. But lets concentrate on just fixing the python.bin deadlock in this
commit.)
The PyThreadDetach antiguard just covering the xInvocation->getValue call in the
"or a property" case had been added with
e0a1cd4dc7 "fixed a deadlock", presumably without
taking into account that the xInvocation->hasMethod/hasProperty calls are
equally problematic.
Change-Id: I2483949df8213c3397a674be190224ee58c95c02
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132428
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Andrea Gelmini