2012/4/27 Patrick Ohly <patrick.o...@intel.com>: > On Wed, 2012-04-25 at 15:26 +0200, Krzesimir Nowak wrote: >> Small status update: >> >> I got a sort of hickup, because suddenly tests stopped working - >> running syncevolution via process subprocess module caused it to hang, >> so tests were ending with errors after timeout. After googling a bit >> about it I thought that using pipes to gather output from >> syncevolution is the culprit - a deadlock may happen when output is so >> large that it fills the pipe completely, so subprocess is blocked >> during writing, because it waits for the pipe to be empty. Pipes are >> emptied by reading from them, but that happen only after subprocess >> finishes. But apparently that was not that - I changed runCmdline to >> use just files, but hanging still happened. I tried running tests >> after setting minimal environment needed for running the tests (PATH >> and SYNCEVOLUTION_TEMPLATE_DIR) and the tests worked. It turned out >> that G_SLICE env var set to "always-malloc" was messing something up. >> What? I do not know and I was not investigating it - I have lost too >> much time on it already. > > I'll try to reproduce that in the nightly test platforms. > >> Currently tests are in cmdline-tests-master branch which is rebased >> against today's master: >> https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commits/cmdline-tests-master >> (you will most probably get "503 Service Unavailable", I wonder when >> word "gitorious" will hit the common directory as a synonym of being >> crappy, slow or other negative adjectives) > > Migration to freedesktop.org is going to happen soonish. > >> Tests not ported: >> testFutureConfig >> testPeerConfigMigration >> testContextConfigMigration >> testOldConfigure >> >> Tests failing on my computer: >> testConfigureSource: >> AssertionError: differences between expected and actual text >> >> .internal.ini:contextMinVersion = 1 >> .internal.ini:contextCurVersion = 1 >> config.ini:# logdir = >> config.ini:# maxlogdirs = 10 >> config.ini:deviceId = fixed-devid >> sources/addressbook/config.ini:backend = file >> sources/addressbook/config.ini:database = file://tmp/test >> - sources/addressbook/config.ini:databaseFormat = text/x-vcard >> ? ---- >> + sources/addressbook/config.ini:databaseFormat = /x-vcard >> sources/addressbook/config.ini:# databaseUser = >> sources/addressbook/config.ini:# databasePassword = > > Cut-and-paste error from C++. > >> testItemOperations: >> AssertionError: differences between expected and actual text >> >> - BEGIN:VCARD >> + BEGIN >> - VERSION:3.0 >> ? ---- >> + VERSION >> - FN:John Doe >> - N:Doe;John;;; >> - END:VCARD >> + FN >> + N >> + END > > A bug in the Python version of createFiles() - str.split() splits into > many components and threw away the parts after the second or higher > colon. > >> testMigrate and testMigrateAutoSync: >> AssertionError: syncevolution command failed. >> Output: >> >> Separate stderr: >> [ERROR] Server 'scheduleworld@default' has not been configured yet. > > $HOME had to be set to find the really, really old ~/.sync4j config > files. > >> testMigrateContext: >> AssertionError: 'sources/addressbook/config.ini:databaseFormat = >> text/vcard' not found in 'long long text, will not paste it as a whole >> here' >> Relevant line of this ''long long text...' is: >> 'sources/addressbook/config.ini:# databaseFormat = ' > > Have not seen this myself after fixing the other things. > >> Also, testConfigure is failing without workarounds there - stripping >> the last newline from expected output. It is marked as 'WORKAROUND', >> so it is easy to grep. > > Not looked at yet. > > On current master I ran into issues with running a lot of syncs inside > client-test: at some point fork() starts to fail with "out of memory". > In runs which complete, valgrind doesn't show any major leaks. I don't > know yet whether that is because the process really starts allocating > lots of memory without freeing it at the end or an artifact of running > under valgrind. > > Either way, running a sync inside a forked process will solve resp. work > around the issue. Maximum memory consumption is still something which > needs to be investigated, but first I want to get the "sync in forked > process" code merged. > > I've pushed my fixes into a cmdline-tests-master branch and will rebase > another branch in preparation for testing and merging. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > >
Thanks for finding and fixing the issues. I also have pushed one last commit to my branch removing most of the C++ tests from Cmdline.cpp. _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution
