Apache OpenOffice (AOO) Bugzilla – Issue 64870
add a new backend
Last modified: 2013-07-30 02:17:45 UTC
This is a placeholder Issue for our database backend, dbbe, which should substantially lower cold-start performance.
Feel free to change the type to PATCH as soon as you attach a patch. Thx, Stefan
Reassigned.
Hmm? What is "our database backend", why does it "lower cold-start performance" (btw: I hope it will *improve* performance :), and what do I have to do with this?
Ah, found the description in the CWS. However, since I'm not planning to work at this (and I suppose nobody really expects :), I'm certainly the wrong owner. Just because I'm the database project's lead doesn't mean every issue bearing a "database" in its description is mine.
fixed in configdbbe
Set verified
I encountered a number of problems: 1 Building on unxlngi6.pro fails with three warnings, I assume the below would be the right fix: ---8<--- Index: source/dbbe/Record.cxx =================================================================== RCS file: /cvs/util/configmgr/source/dbbe/Attic/Record.cxx,v retrieving revision 1.1.2.16 diff -u -r1.1.2.16 Record.cxx --- source/dbbe/Record.cxx 21 Jul 2006 04:40:02 -0000 1.1.2.16 +++ source/dbbe/Record.cxx 7 Aug 2006 15:41:04 -0000 @@ -171,9 +171,9 @@ void Record::RecordImpl::bytesex() { - OSL_SWAPQWORD(blobSize); - OSL_SWAPQWORD(numChildren); - OSL_SWAPQWORD(date); + blobSize = OSL_SWAPQWORD(blobSize); + numChildren = OSL_SWAPQWORD(numChildren); + date = OSL_SWAPQWORD(date); } ---8<--- 2 At least on unxlngi6.pro (after locally fixing 1), program/dbbe_enable.sh is not marked as executable (you need to specify this in scp2). 3 At least on unxlngi6.pro (after locally fixing 1--2), program/dbbe_enable.sh cannot be started from within a tcsh etc., as it lacks "#!/bin/sh" as its first line. 4 At least on unxlngi6.pro (after locally fixing 1--3), cd .../program && ./dbbe_enable.sh appears to fail: ---8<--- This script enables the database driven backend, dbbe for the config data in share/registry It will delete the .xcu files on import and create config.db in their place Press control-c now if you do not want to do this /export/home/sb93797/source/configdbbe/ooo/program /export/home/sb93797/source/configdbbe/ooo/program ./dbbe_enable.sh: line 65: cd: /export/home/sb93797/source/configdbbe/ooo/program/./dbbe_enable.sh/program: Not a directory ./dbbe_enable.sh: line 68: 10411 Aborted ./dbbeutil.bin -d=${CONFDIR}/config.db -p import ${CONFDIR}/data ./dbbe_enable.sh: line 69: 10413 Aborted ./dbbeutil.bin -d=${CONFDIR}/config.db -p import ${CONFDIR}/modules ./dbbe_enable.sh: line 70: 10415 Aborted ./dbbeutil.bin -d=${CONFDIR}/config.db -p import ${CONFDIR}/res /export/home/sb93797/source/configdbbe/ooo/program dbbe is now enabled ---8<---
... 5 Do we want to inform the user (if yes, how?) that there is some dbbe_enable script? (Is there also a dbbe_disable script comming?)
1) fixed 2 & 3) I did this in purpose, as I wanted to make it non-trivial for a user to trigger this action. I wanted there to be the requirement to do a sh dbbe_enable.sh as an extra step. This can be fixed, if required. 4) I could not reproduce this issue. The logic for figuring out the program and share directories is simple and probably easy to fool. Is it safe to assume that the added #!/bin/sh executed the script with a bourne shell? 5) I hadn't planned on doing advertising the presense of the script other than on the wiki and mailing lists. I haven't crafted a disable script, but it can be done, if required.
AFAIK: 1) fixed 2) won't fix 3) won't fix 4) couldn't reproduce 5) won't fix
Created attachment 38457 [details] configmgr patch for Solaris
6 The attached configmgr.patch is needed to compile on Solaris (unxsols4). The patch compiles fine on unxlngi6 and unxsols4, but I did not bother to check wntmsci10---please do so when you commit the patch. 7 cd .../program && bash dbbe_enable.sh indeed works on Linux ("sh" instead of "bash" fails on Solaris, as the script obviously uses bash extensions). 8 cd .../program && bash dbbe_enable.sh fails on Solaris, as dbbeutil.bin segfaults (but I cannot invest more time into this): ---8<--- This script enables the database driven backend, dbbe for the config data in share/registry It will delete the .xcu files on import and create config.db in their place Press control-c now if you do not want to do this /export/home/sb93797/ooo/opt/openoffice.org2.0/program /export/home/sb93797/ooo/opt/openoffice.org2.0/program key= "data::org.openoffice.Office.UI.CalcCommands::" dbbe_enable.sh: line 67: 28540 Segmentation Fault ./dbbeutil.bin -d=${CONFDIR}/config.db -p import ${CONFDIR}/data key= "modules::org.openoffice.Office.Common::Common-base" dbbe_enable.sh: line 68: 28541 Segmentation Fault ./dbbeutil.bin -d=${CONFDIR}/config.db -p import ${CONFDIR}/modules key= "res::org.openoffice.Office.UI.BaseWindowState::en-US" dbbe_enable.sh: line 69: 28542 Segmentation Fault ./dbbeutil.bin -d=${CONFDIR}/config.db -p import ${CONFDIR}/res /export/home/sb93797/ooo/opt/openoffice.org2.0/program dbbe is now enabled ---8<---
Since I don't have a Solaris machine, this is a little hard for me. Can you give me a backtrace?
Will try to find some time soon.
@mikeleib: The stack of unxsols4.pro's third dbbeutil.bin segfault is =>[1] configmgr::dbbe::Record::SubLayerLen(0xfecec000, 0x0, 0x0, 0x1f74, 0x0, 0x1fb8), at 0x21b0c [2] configmgr::dbbe::Record::Marshal(0xffbfe534, 0xffbfe44c, 0x1, 0x1, 0x35, 0xfeef6088), at 0x21bfc [3] configmgr::dbbe::Database::putKey(0x39e88, 0xfece0010, 0xffbfe534, 0x39e88, 0xff0000, 0x1), at 0x2345c [4] configmgr::dbbe::Database::putKey(0x39e88, 0xffbfe5c0, 0xffbfe534, 0x3b1bc, 0x3b1bc, 0xfece0008), at 0x2341c [5] configmgr::dbbe::databaseLoadStore::ensureParent(0xffbfebe8, 0xffbfe5c0, 0xffbfe5bc, 0x0, 0xffff8400, 0x37c10), at 0x1f1fc [6] configmgr::dbbe::databaseLoadStore::importFile(0xffbfebe8, 0x78, 0x0, 0x27be6, 0x1, 0x37c10), at 0x1f5cc [7] configmgr::dbbe::databaseLoadStore::importPathInnerLoop(0xffbfebe8, 0x48, 0xffbfeb64, 0x0, 0x1, 0x400), at 0x1fb88 [8] configmgr::dbbe::databaseLoadStore::importPathInnerLoop(0xffbfebe8, 0x48, 0xffbfeb64, 0x0, 0x1, 0x400), at 0x1fb38 [9] configmgr::dbbe::databaseLoadStore::importPathInnerLoop(0xffbfebe8, 0x48, 0xffbfeb64, 0x0, 0x1, 0x400), at 0x1fb38 [10] configmgr::dbbe::databaseLoadStore::importPathInnerLoop(0xffbfebe8, 0x48, 0xffbfeb64, 0x0, 0x1, 0x400), at 0x1fb38 [11] configmgr::dbbe::databaseLoadStore::importPathInnerLoop(0xffbfebe8, 0x48, 0xffbfeb64, 0x0, 0x1, 0x400), at 0x1fb38 [12] configmgr::dbbe::databaseLoadStore::importPathInnerLoop(0xffbfebe8, 0x48, 0xffbfeb64, 0x0, 0x1, 0x0), at 0x1fb38 [13] configmgr::dbbe::databaseLoadStore::importPath(0xffbfebe8, 0xffbfee74, 0x0, 0xfeefa1e8, 0x48, 0x63), at 0x1fffc [14] sal_main(0x5, 0xffbfecd4, 0x0, 0x4, 0x10, 0x39e88), at 0x16a5c [15] main(0x5, 0xffbfecd4, 0xffbfecec, 0x38400, 0xff110240, 0xff110280), at 0x16748
@sb: I think the problem on big endian machines has been fixed. Could you try again on your solaris machine? Thanks.
@mikeleib: Did you integrate the configmgr.patch I had attached to this issue? I assume not, as I again have trouble compiling the latest version of the CWS on Solaris. Please integrate the patch, I will re-try to compile the latest version then.
@sb: I made a clerical error in my checkin and it should be fixed, I hope. :-)
cd .../program && bash dbbe_enable.sh works now on unxsols4.pro, but starting soffice[.bin] then leads to a SIGSEGV: (dbx) where current thread: t@1 [1] 0xfd7ad63c(0xff080000, 0x0, 0xc, 0x0, 0xf9d0f7b9, 0x3d7e44d), at 0xfd7ad63c [2] rtl_arena_free(0xff080000, 0xf5f9136c, 0x80000, 0xfd7e95d0, 0xfb4821c4, 0xff080030), at 0xfd7ae2d4 [3] rtl_freeMemory(0xf5f91374, 0xa3028, 0x1, 0xfd7edd74, 0x55c, 0x400), at 0xfd7ab480 [4] 0xfb481178(0xf5f91374, 0x0, 0x0, 0xf8b4f35c, 0xffbfd6d0, 0xa40a0), at 0xfb481178 [5] uno_type_destructData(0xffbfd6d0, 0xa40a0, 0xf8b4f35c, 0x2b90, 0x604, 0x400), at 0xfb47d0fc =>[6] configmgr::backend::MultiStratumBackend::searchSupportingStrata(this = ???, nNumLayers = ???, aEntity = CLASS, aComponent = CLASS) (optimized), at 0xf8b4b838 (line ~629) in "multistratumbackend.cxx" [7] configmgr::backend::MultiStratumBackend::listLayers(this = ???, aComponent = CLASS, aEntity = CLASS) (optimized), at 0xf8b4af78 (line ~560) in "multistratumbackend.cxx" [8] configmgr::backend::MultiStratumBackend::listOwnLayers(this = ???, aComponent = CLASS) (optimized), at 0xf8b4add0 (line ~523) in "multistratumbackend.cxx" [9] configmgr::backend::BackendAccess::getLayers(this = ???, aComponent = CLASS, aOptions = CLASS) (optimized), at 0xf8b2e800 (line ~877) in "backendaccess.cxx" [10] configmgr::backend::BackendAccess::getNodeData(this = ???, aRequest = CLASS, _aTemplateProvider = ???, aListener = ???) (optimized), at 0xf8b2c990 (line ~615) in "backendaccess.cxx" [11] configmgr::backend::CacheController::loadDirectly(this = ???, _aRequest = CLASS, _bAddListenter = ???) (optimized), at 0xf8adfa34 (line ~760) in "cachecontroller.cxx" [12] configmgr::backend::CacheController::loadComponent(this = ???, _aRequest = CLASS) (optimized), at 0xf8ade204 (line ~451) in "cachecontroller.cxx" [13] configmgr::TreeManager::requestSubtree(this = ???, aSubtreePath = CLASS, _aOptions = CLASS) (optimized), at 0xf8ae63cc (line ~344) in "treemanager.cxx" [14] configmgr::OProviderImpl::requestSubtree(this = ???, aSubtreePath = CLASS, _aOptions = CLASS) (optimized), at 0xf8be04d0 (line ~428) in "providerimpl.cxx" [15] configmgr::OProviderImpl::buildUpdateAccess(this = ???, _rAccessor = CLASS, _aOptions = CLASS, nMinLevels = ???) (optimized), at 0xf8be142c (line ~623) in "providerimpl.cxx" [16] configmgr::OConfigurationProviderImpl::createUpdateAccess(this = ???, aArgs = CLASS) (optimized), at 0xf8be9720 (line ~140) in "confproviderimpl2.cxx" [17] configmgr::OConfigurationProvider::createInstanceWithArguments(this = ???, aServiceSpecifier = CLASS, aArguments = CLASS) (optimized), at 0xf8be55f4 (line ~364) in "confprovider2.cxx" [18] utl::ConfigManager::AcquireTree(0xffbfdf64, 0x800, 0x27dd38, 0xfde72a40, 0xf8be8504, 0x0), at 0xfd9c9b08 [19] utl::ConfigManager::AddConfigItem(0xffbfdfd4, 0x1e7700, 0x27dd38, 0xfda237d8, 0xae0, 0x800), at 0xfd9c9520 [20] utl::ConfigItem::ConfigItem(0x27dd38, 0xffbfe134, 0x0, 0xfda237d8, 0x10000, 0x518c90), at 0xfd9c0dcc [21] framework::AddonsOptions_Impl::AddonsOptions_Impl(0x27dd38, 0x800, 0xc00, 0x13798, 0x85c, 0xf5fa6848), at 0xf6d67cec [22] framework::AddonsOptions::AddonsOptions(0x1, 0xf6dba3bc, 0xf62794a0, 0x0, 0xd68, 0x27dd38), at 0xf6d75124 [23] 0xf6279740(0xf6558810, 0xf64f83f8, 0x0, 0x0, 0x0, 0xffbfe32c), at 0xf6279740 [24] 0xf6277c8c(0xf6558810, 0xfeb75a54, 0x1f, 0x1f, 0x8, 0x1), at 0xf6277c8c [25] 0xf629bda0(0xf6558810, 0xffbfe644, 0x0, 0xffbfe5c8, 0xf655883c, 0xc0), at 0xf629bda0 [26] 0xf61f4c18(0xf61fadc4, 0xffbfe6c0, 0xf62a37f8, 0x1, 0xf5f9015c, 0xf6506d60), at 0xf61f4c18 [27] 0xf61f092c(0xf754218c, 0xffbfe890, 0x1, 0x0, 0xffbfe6c8, 0x0), at 0xf61f092c [28] desktop::Desktop::Main(0xffbfeb90, 0x267ce8, 0x38064, 0xffbfe9ac, 0xffbfea04, 0xffbfea18), at 0x2bee4 [29] 0xfe521244(0x0, 0xfe7e52dc, 0x1, 0x0, 0xfe7e52dc, 0xfe7efe0c), at 0xfe521244 [30] SVMain(0x0, 0x400, 0x7d70c, 0x7fd74, 0x7a0, 0x400), at 0xfe5213dc [31] sal_main(0x1, 0xffbfec94, 0x10000, 0x7d70c, 0x4, 0x0), at 0x250e4 [32] main(0x1, 0xffbfec94, 0xffbfec9c, 0x7f800, 0xff0b0ac0, 0xff0b0b00), at 0x25074 (dbx)
It works for me in Solaris. The problem was that in getKey, it allocated a Record instead of a RecordImpl and then threw it away. However, in big endian machines, it did byte-flipping before throwing it away, which corrupted memory (because Record is smaller than RecordImpl).
Reset assignee on issues not touched by assignee in more than 2000 days.