Re: [SyncEvolution] server class + fork/exec dbus-server + command line testing

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-syncevolut... > (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.