It now probably becomes a question for Stephan. See below.
On Tue, Jun 02, 2015 at 03:17:16PM +0200, Lionel Elie Mamane wrote:
> On Tue, Jun 02, 2015 at 03:12:51PM +0200, Noel Grandin wrote:
>> I would suggest something like this in ODriverDelegator::flushConnections():
>> take_mutex();
>> std::vector<Connection> tmp = m_aConnections;
>> release_mutex();
>> for (Connection conn : tmp)
>> conn.flush();
>> so that the mutex is not held during the problematic phase
> That makes sense. Will try that. Thanks!
It does not solve my problem, because the same mutex is taken deeper
in the stack:
#23 0x00002abc1b1a9fd8 in connectivity::hsqldb::ODriverDelegator::preCommit
(this=0x2d24ef0, aEvent=...)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/connectivity/source/drivers/hsqldb/HDriver.cxx:65
#24 0x00002abc18bb7081 in OStorage::BroadcastTransaction
(this=this@entry=0x3578030,
nMessage=nMessage@entry=1 '\001')
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/package/source/xstor/xstorage.cxx:2094
#25 0x00002abc18bc66e3 in OStorage::commit (this=0x3578030)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/package/source/xstor/xstorage.cxx:3937
#26 0x00002abc13f336ad in dbaccess::tools::stor::commitStorageIfWriteable (
_rxStorage=uno::Reference to (OStorage *) 0x3578038)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/dbaccess/source/core/misc/sdbcoretools.cxx:139
#27 0x00002abc13ef82cd in
dbaccess::DocumentStorageAccess::commitEmbeddedStorage (this=0x35ba790,
_bPreventRootCommits=_bPreventRootCommits@entry=false)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/dbaccess/source/core/dataaccess/ModelImpl.cxx:290
#28 0x00002abc13efc0b2 in dbaccess::ODatabaseModelImpl::commitEmbeddedStorage
(this=0x35bbd20,
_bPreventRootCommits=_bPreventRootCommits@entry=false)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/dbaccess/source/core/dataaccess/ModelImpl.cxx:887
#29 0x00002abc13eb58c8 in dbaccess::ODatabaseSource::flushed (this=0x35b7c60)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/dbaccess/source/core/dataaccess/datasource.cxx:1306
#30 0x00002abc13eae005 in dbaccess::FlushNotificationAdapter::flushed
(this=0x318ec50, rEvent=...)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/dbaccess/source/core/dataaccess/datasource.cxx:172
(...)
#34 0x00002abc1b1a07f1 in connectivity::hsqldb::OHsqlConnection::flush
(this=0x3577db0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/connectivity/source/drivers/hsqldb/HConnection.cxx:168
#35 0x00002abc1b1a9ba3 in
connectivity::hsqldb::ODriverDelegator::flushConnections (this=0x2d24ef0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/connectivity/source/drivers/hsqldb/HDriver.cxx:629
But let's take it from the other side...
connectivity::hsqldb::ODriverDelegator::preCommit does:
654 Reference<XConnection> xConnection(i->first,UNO_QUERY);
655 if ( xConnection.is() )
656 {
657 Reference< XStatement> xStmt = xConnection->createStatement();
Now, this goes through a whole rigmarole:
#6 0x00002abc1b6e90d3 in AffineBridge::v_callInto_v (this=0x2d29b50,
pCallee=0x2abbf94eedbe <s_pull(va_list*)>,
pParam=0x2abc0fd9bdb0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/AffineBridge/AffineBridge.cxx:250
#7 0x00002abc1b6e9b07 in cppu::Enterable_call_callInto_v (context=0x2d29b50,
pCallee=0x2abbf94eedbe <s_pull(va_list*)>, pParam=0x2abc0fd9bdb0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/include/cppu/Enterable.hxx:69
#8 0x00002abc1b8eee97 in cppu::Enterable::callInto_v (this=0x2d29b50,
pCallee=pCallee@entry=0x2abbf94eedbe <s_pull(va_list*)>,
pParam=pParam@entry=0x2abc0fd9bdb0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/include/cppu/Enterable.hxx:53
#9 0x00002abc1b8eeccf in Base::v_callInto_v (this=0x2d29eb0,
pCallee=0x2abbf94eedbe <s_pull(va_list*)>,
pParam=0x2abc0fd9bdb0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/helper/purpenv/helper_purpenv_Environment.cxx:508
#10 0x00002abc1b8eef6f in cppu::Enterable_call_callInto_v (context=0x2d29eb0,
pCallee=0x2abbf94eedbe <s_pull(va_list*)>, pParam=0x2abc0fd9bdb0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/include/cppu/Enterable.hxx:69
#11 0x00002abbf94ef997 in cppu::Enterable::callInto_v
(this=this@entry=0x2d29eb0,
pCallee=pCallee@entry=0x2abbf94eedbe <s_pull(va_list*)>,
pParam=pParam@entry=0x2abc0fd9bdb0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/include/cppu/Enterable.hxx:53
#12 0x00002abbf94efaac in cppu::Enterable::callInto (this=this@entry=0x2d29eb0,
pCallee=pCallee@entry=0x2abbf94eedbe <s_pull(va_list*)>)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/include/cppu/Enterable.hxx:90
#13 0x00002abbf94eeeb4 in s_callInto_v (pEnv=pEnv@entry=0x2d29900,
pCallee=pCallee@entry=0x2abbf94ef0b9 <s_environment_invoke_vv(va_list*)>,
pParam=pParam@entry=0x2abc0fd9bee0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/uno/EnvStack.cxx:233
#14 0x00002abbf94eef7e in s_callInto (pEnv=0x2d29900,
pCallee=pCallee@entry=0x2abbf94ef0b9 <s_environment_invoke_vv(va_list*)>)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/uno/EnvStack.cxx:244
#15 0x00002abbf94ef316 in s_environment_invoke_v (pCurrEnv=0x0,
pTargetEnv=pTargetEnv@entry=0x2d29900,
pCallee=pCallee@entry=0x2abc1b8f07c6 <s_dispatcher_v(va_list*)>,
pParam=pParam@entry=0x2abc0fd9c050)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/uno/EnvStack.cxx:300
#16 0x00002abbf94ef384 in uno_Environment_invoke_v
(pTargetEnv=pTargetEnv@entry=0x2d29900,
pCallee=pCallee@entry=0x2abc1b8f07c6 <s_dispatcher_v(va_list*)>,
pParam=pParam@entry=0x2abc0fd9c050)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/uno/EnvStack.cxx:312
#17 0x00002abbf94ef456 in uno_Environment_invoke (pEnv=0x2d29900,
pCallee=0x2abc1b8f07c6 <s_dispatcher_v(va_list*)>)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/uno/EnvStack.cxx:321
#18 0x00002abc1b8f0ccc in Proxy::dispatch (this=this@entry=0x3577660,
pReturnTypeRef=pReturnTypeRef@entry=0x3023920, pParams=pParams@entry=0x0,
nParams=nParams@entry=0,
pMemberType=pMemberType@entry=0x3436a40,
pReturn=pReturn@entry=0x2abc0fd9c2f0, pArgs=0x2abc0fd9c2e0,
ppException=0x2abc0fd9c390)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/helper/purpenv/helper_purpenv_Proxy.cxx:445
#19 0x00002abc1b8efc7d in s_Proxy_dispatch (pUnoI=0x3577660,
pMemberType=pMemberType@entry=0x3436a40,
pReturn=pReturn@entry=0x2abc0fd9c2f0, pArgs=pArgs@entry=0x2abc0fd9c2e0,
ppException=ppException@entry=0x2abc0fd9c390)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/cppu/source/helper/purpenv/helper_purpenv_Proxy.cxx:170
#20 0x00002abc0f3f1fd2 in cpp2uno_call (pThis=pThis@entry=0x2d2ca80,
pMemberTypeDescr=0x3436a40,
pReturnTypeRef=pReturnTypeRef@entry=0x3023920, nParams=nParams@entry=0,
pParams=pParams@entry=0x0,
gpreg=0x2abc0fd9c720, gpreg@entry=0x2abc0fd9c710, fpreg=0x2abc0fd9c740,
ovrflw=0x2abc0fd9c790,
pRegisterReturn=0x2abc0fd9c6f0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:186
#21 0x00002abc0f3f2a6a in cpp_vtable_call (nFunctionIndex=<optimized out>,
nVtableOffset=0,
gpreg=0x2abc0fd9c710, fpreg=0x2abc0fd9c740, ovrflw=0x2abc0fd9c790,
pRegisterReturn=0x2abc0fd9c6f0)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/bridges/source/cpp_uno/gcc3_linux_x86-64/cpp2uno.cxx:377
#22 0x00002abc0f409c12 in privateSnippetExecutor ()
from
/home/master/src/libreoffice/workdirs/libreoffice-5-1/instdir/program/libgcc3_uno.so
#23 0x00002abc1b1a9fd8 in connectivity::hsqldb::ODriverDelegator::preCommit
(this=0x2d24ef0, aEvent=...)
at
/home/master/src/libreoffice/workdirs/libreoffice-5-1/connectivity/source/drivers/hsqldb/HDriver.cxx:657
#24 0x00002abc18bb7081 in OStorage::BroadcastTransaction
(this=this@entry=0x3578030,
The problem is essentially the serializing that happens at
AffineBridge::v_callInto_v.
Now, I guess that the whole privateSnippetExecutor / cpp_vtable_call /
cpp2uno_call / s_Proxy_dispatch / ... / AffineBridge::v_callInto_v for
a C++-to-C++ call is somehow linked to the fact that the calling code
does not know the object that implements the XConnection
interface. Can I avoid it in some way? For example, I *know* that
m_xConnection is a connectivity::java_sql_connection.
If I use that fact, can I avoid going through AffineBridge::v_callInto_v ?
--
Lionel
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
