"Testing" was updated from Debian Wheezy to the current Debian Testing
with GNOME 3.8. This triggered some minor new leaks and changed some existing
ones.
The leak started showing up after switching to GNOME 3.8, independent
of any change in SyncEvolution. Looks like a bug in GNOME. I tried
to debug it, but gave up because it seems to be timing dependent such
that the error path was not triggered when running without valgrind.
The platform specific code which is of no value unless you run a
specific desktop now gets compiled as part of shared libraries, just
like the storage backends. The advantage is that the rest of
SyncEvolution keeps running even if one of these shared libraries
cannot be loaded due to missing depdendencies. syncevolution.org
packages will not declared these dependencies, to allow installing
each package without forcing the installation of unwanted libraries.
Distros can package the platform code separately.
Another advantage is reduced code duplication (password load/store
was duplicated in command line and D-Bus server).
Technically this uses almost the same mechnism as loadable sync
sources. The code resides in src/backends/[kde|gnome], where the
autotool magic finds the *Register.cpp files automatically and
includes them into executables. These files contain global singletons
which, when initialized, connect platform specific code to new signals
in the core (init, password load/save).
The actual code is in the backend libraries. Because
SE_ARG_ENABLE_BACKEND() is not used (in favor of the traditional
enable macros), linking against these libs must be set up by adding
them to the (now slightly misnamed) SYNCSOURCES variable in the
configure fragments.
Seen on Debian Testing, 64 bit mode, in libdb 5.1.29-1.
Further investigation showed that it is probably harmless,
goes away when compiling libdb with initialization of
padding bytes.
Reported to Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662917
I've tracked the root cause in __ham_add_el() in src/hash/hash_page.c:
if (is_databig) {
doff.type = H_OFFPAGE;
===> UMRW_SET(doff.unused[0]);
===> UMRW_SET(doff.unused[1]);
===> UMRW_SET(doff.unused[2]);
UMRW_SET is a NOP unless --enable-umrw is used during
configure. Compiling with --enable-umrw avoids the valgrind warning.
The unitialized value is used in a comparison of a checksum with 0.
I can convince myself that this is probably okay, because it doesn't
matter whether some of the data the checksum was calculated over
was uninitialized as long as it doesn't change later on.
But nevertheless, having to deal with such random valgrind errors
while debugging other code isn't nice. Please consider using
--enable-umrw when compiling libdb.
syncevo-local-sync dies with a segfault in libdl after the
TestLocalSync.testConcurrency D-Bus tests completes, but only when
running under valgrind. Ignore that problem via a suppression.
Made the previous suppression for dbus_server_listen() more generic,
added suppressions for dbus_setup_server(). Covers some small
leaks in code which is obsolete and hard to fix.
The errors are minor and don't seem to be caused by SyncEvolution
(dbus_server_disconnect() is called). Will go away once we move away
from libdbus and/or when running one sync session per server (and thus
not creating multiple servers?).
When setting up a connection fails, g_dbus_connection_new_for_address_sync()
leaks some memory. Nothing that is caused by our code. Same for a leak
inside the GIO helper thread.
Saving and retrieving a password in GNOME keyring leaks some small
amount of memory. In particular saving doesn't get anything back
except for an integer ID, so it seems unlikely that this is caused
by our code.
gnutls + glib-networking cause warnings about reading slightly beyond
the end of a buffer in the asn code when exchanging data with
Google. Nothing we can do about that, ignore it.
Tested with local tests (Client::Source SyncEvolution), valgrind 3.4.1.SVN-9098-1883,
Evolution 2.22.3.1, on Ubuntu 8.04 in 64 bit mode. Some stack backtraces were
slightly different, some problems are new. None seem to be caused by us.
The files were originally created for:
sys = Debian Etch
evo = Evolution trunk ~ 2.22
client = Funambol C++ client library post 6.5
git-svn-id: https://zeitsenke.de/svn/SyncEvolution/trunk@520 15ad00c4-1369-45f4-8270-35d70d36bdcd
Jonas Smedegaard
Patrick Ohly
Patrick Ohly