Re: [Evolution-hackers] Isolated unit test status report
On Mon, 2013-02-25 at 18:25 +0900, Tristan wrote: > Perhaps, if performance at connection time is very slow, we should > take an approach that the factory connection be released when > all EBookClients are finalized (with a sort of internal ref-counting > logic)... if of course, performance of opening the book is such > a bottleneck. Hi, it was done exactly that way before Matthew's change. I do not see a point of changing it, except of the slowness. But let's see, I can be always wrong. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Isolated unit test status report
On Mon, 2013-02-25 at 19:46 +0900, Tristan wrote: [...] > I've made some fixes and now test cases are working much better > with the workarounds in place. I think the final touch will be > to run the module-prompter test relocated and then make check > will be completely passing again. Correction, after successfully running the user prompter test I found that it is in fact a functional test and not a unit test and as such has no place in running under make check (as it involves user interaction and pops up a series of dialogs). Instead I'm just moving that from TESTS to noinst_PROGRAMS. Unfortunately make check still does not pass, due to various failures in the calendar tests. These same tests actually pass in our 3.6 based openismus-work branch. At least some of the failures are due to the regression reported in bug 692802. Cheers, -Tristan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Isolated unit test status report
On Sun, 2013-02-24 at 20:54 -0500, Matthew Barnes wrote:
> On Sat, 2013-02-23 at 23:38 +0900, Tristan wrote:
> > This indicates that somewhere, in the client or server, we
> > are leaking references to the GDBusConnections. I've tested
> > this in raw GIO (and added a test case there) to ensure it
> > is indeed possible to stop/start the GTestDBus between tests,
> > the problem is clearly an ugly bug to be fixed in EDS.
>
> I suspect this might be related to the factory proxy object that we
> create in the background and leave lying around as a global variable.
>
> We could try letting EBookClient create its own EDBusAddressBookFactory
> proxy, call its OpenAddressBook method, and then immediately destroy it.
>
> That would simplify the code, eliminate the global variable, and quite
> possibly fix the GDBusConnection leak (if my guess is right).
>
> I'll prototype this for 3.9. I think I've pulled enough D-Bus stunts
> for one release already.
>
>
> > This is due to a race condition in e_client_remove_sync(),
> > this call is made at the end of a test case.. which results
> > in the ESource being removed from the ESourceRegistry server.
> >
> > What happens when the cache-reaper module is loaded, is that
> > the 'test-address-book' source is removed /some time after/
> > e_client_remove_sync() completes... sometimes this happens
> > right in the middle of the following test case.
>
> Probably another side effect of (A).
>
> In the interim, it might help if the ESource's unique ID were actually
> unique for each test case, instead of a static ID for all cases.
>
> Instead of "test-address-book" use "test-address-book-N" where 'N' is
> the test case number or some other increasing integer.
I had been trying to avoid that since the beginning ;-)
But... for now let's roll with that until we can fix the other issues.
I've made some fixes and now test cases are working much better
with the workarounds in place. I think the final touch will be
to run the module-prompter test relocated and then make check
will be completely passing again.
I've made four relevant commits, two of them touch outside
the test casing fixture and simply add environment variable
support to allow relocation of various loaded modules (and
this fixes the breakage that is only noticeable where EDS
has _never_ been installed, i.e. regarding missing module
directories in ${prefix}/lib/evolution-data-server).
commits listed below.
Cheers,
-Tristan
commit 04906b9b666b14b30667e7180ac1ae17e5258258
Author: Tristan Van Berkom
Date: Mon Feb 25 19:35:20 2013 +0900
test-client-view-operations.c: Now test both direct access and indirect
access
This works properly now since we fixed (or worked around) issues in the
test fixtures. Since we use a separate ESource UID (sandbox) for each
test case this now works properly.
commit 79041f15c816c7f7b9ad90657c928da94e245e6c
Author: Tristan Van Berkom
Date: Mon Feb 25 19:33:04 2013 +0900
Some changes to the isolated test fixture
a.) Setup EDS_REGISTRY_MODULES to use the local cache-reaper module
b.) Setup EDS_CAMEL_PROVIDER_DIR to use the local provider
c.) Added "source_name" and use separate ESource uids between tests,
each test in the suite uses a separate ESource name
Note that 'c' is a stop-gap solution to the problem of not being able to
properly shut-down the whole test D-Bus environment between tests, it
should be removed once we can address that problem.
commit 85afb581c3e5253e77c906c175a93dee5f7705b3
Author: Tristan Van Berkom
Date: Mon Feb 25 19:28:04 2013 +0900
Make the Camel provider modules relocatable
This simply adds an environment variable allowing us to load the local
provider from a relocated location in the case we run 'make check'
without installing (this avoids some warnings and helps to isolate the
test environment).
commit 410a56cd3fd1793f6c523e416f2d73c4baf2fc05
Author: Tristan Van Berkom
Date: Mon Feb 25 19:26:45 2013 +0900
Make the ESourceRegistryServer modules relocatable like addressbook &
calendar
This simply adds an environment variable allowing us to load registry
modules from a relocated location in the case we run 'make check'
without installing (also ensuring that we test the not-yet-installed
environment properly).
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Isolated unit test status report
On Mon, 2013-02-25 at 09:23 +0100, Milan Crha wrote: > On Sun, 2013-02-24 at 23:01 -0500, Matthew Barnes wrote: > > I went ahead and committed it for 3.8. > > > > We'll see if this has any impact on the GDBusConnection leak, but it's > > an improvement regardless. > > Hi, > easy to test it with Tristan's [1], isn't it? You'll realize it'll not > help, just the opposite, as I expect that creating a factory connection > for each created book/calendar client only adds more things to be done > on various layers, thus makes opening generally slower. Milan, the factory connection is certainly something to consider here. While you have a point that, we still wont be able to test it until EBookClient/ECalClient can properly be finalized (i.e. the bug you refer to regarding imbalanced reference counts needs also to be fixed), we still need a way to release that factory connection. Perhaps, if performance at connection time is very slow, we should take an approach that the factory connection be released when all EBookClients are finalized (with a sort of internal ref-counting logic)... if of course, performance of opening the book is such a bottleneck. Cheers, -Tristan > > Just my untested opinion. > > The issue with [1] is also related to [2], if it'll help you to properly > fix them both. If you do not like the already available tool for > testing, then I can provide a simple test.c, which will exhibit the same > issue - I only wanted to use something in place, to exhibit the > regression from 3.6 code. > Bye, > Milan > > [1] https://bugzilla.gnome.org/show_bug.cgi?id=693461 > [2] https://bugzilla.gnome.org/show_bug.cgi?id=693464 > > ___ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > https://mail.gnome.org/mailman/listinfo/evolution-hackers ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Isolated unit test status report
On Sun, 2013-02-24 at 23:01 -0500, Matthew Barnes wrote: > I went ahead and committed it for 3.8. > > We'll see if this has any impact on the GDBusConnection leak, but it's > an improvement regardless. Hi, easy to test it with Tristan's [1], isn't it? You'll realize it'll not help, just the opposite, as I expect that creating a factory connection for each created book/calendar client only adds more things to be done on various layers, thus makes opening generally slower. Just my untested opinion. The issue with [1] is also related to [2], if it'll help you to properly fix them both. If you do not like the already available tool for testing, then I can provide a simple test.c, which will exhibit the same issue - I only wanted to use something in place, to exhibit the regression from 3.6 code. Bye, Milan [1] https://bugzilla.gnome.org/show_bug.cgi?id=693461 [2] https://bugzilla.gnome.org/show_bug.cgi?id=693464 ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Required Evolution-code-help
On Mon, 2013-02-25 at 10:31 +0530, samarjit Adhikari wrote: > As suggested, I have open a mapi connection using camel services but > got a crash in g_rec_mutex_lock function. > > Crash debugging attached. it seems the connection has not being > initialized yet. Any help?? Hi, CamelMapiStore and CamelMapiTransport are two different objects, you cannot use CamelMapiStore functions on an instance of CamelMapiTransport. With your other changes, you should be touching only camel-mapi-transport.c, no other file. If you provide *similar* function implementations for CamelServiceClass, those I wrote about in the previous email, for CamelMapiTransport, then you can then check of proper connection status of the CamelMapiTransport, not CamelMapiStore. Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
