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