"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.
libsynthesis leaks some small amount of memory when it gets unloaded.
That's better than trying to free on unload, because it is not clear
how long the instances are needed.
The problem has been fixed in the meantime (00f566 "sqlite addressbook: fix
memory corruption in get_revision") and no longer occurs in an release we test
against.
See https://bugzilla.gnome.org/show_bug.cgi?id=694730
==18552== 25 bytes in 1 blocks are definitely lost in loss record 2,353 of
6,616
==18552== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==18552== by 0xADC3D40: g_malloc (gmem.c:159)
==18552== by 0xADDA3BB: g_strdup (gstrfuncs.c:364)
==18552== by 0x1146400B: get_string_cb (e-book-backend-sqlitedb.c:255)
==18552== by 0x854F1CE: sqlite3_exec (in
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6)
==18552== by 0x114665A2: book_backend_sql_exec_real
(e-book-backend-sqlitedb.c:301)
==18552== by 0x1146666F: book_backend_sql_exec
(e-book-backend-sqlitedb.c:391)
==18552== by 0x11469FC6: e_book_backend_sqlitedb_get_revision
(e-book-backend-sqlitedb.c:3995)
==18552== by 0x1F90480E: e_book_backend_file_open
(e-book-backend-file.c:656)
==18552== by 0x1146C229: book_backend_open (e-book-backend-sync.c:397)
==18552== by 0x11473F26: operation_thread (e-data-book.c:292)
==18552== by 0xADE2181: g_thread_pool_thread_proxy (gthreadpool.c:309)
==18552== by 0xADE1964: g_thread_proxy (gthread.c:797)
==18552== by 0x8E34B4F: start_thread (pthread_create.c:304)
==18552== by 0xB90F70C: clone (clone.S:112)
folks and/or SyncEvolution leak some small amounts of memory,
as reported by valgrind during testing. Ignore these analyzed
problems for now, fix them later.
Some (but not all) of the GDBusMethodInfo structs leak when testing
against the HTTP server (for example, edsfile
Client::Sync::eds_event::testCopy). Tried to find the reason for half
a day, giving up for now and suppressing the issue. Need to look again.
Somehow the auto sync code triggers a valgrind warning when
running the TestFileNotify.testRestart code. That code is
going to be rewritten, so ignore the warning for now.
Ignore everything in ecal/ebook's usage of libdbus *and* glib dbus.
Previously only leaks in glib dbus were ignored and a suppression for
ebook was missing.
This is a single string which leaks in e_contact_new_from_vcard().
We definitely free the contact, so I'm fairly sure that it is not
our code leaking the memory => suppressing the report.
Our valgrind suppression for a libical internal error did not
longer match because it included a long call stack. Simplified
the callstack to the one inside libical and the one level
inside SyncEvolution. This one location has been checked and
definitely is not our fault - other locations might be, so
don't suppress the error there.
Did real sync tests (ical20 + vcard30 testItems) with Ubuntu 8.04,
valgrind valgrind-3.4.1.SVN-9098-1883, 64 bit mode. Some issues in
libsynthesis could be fixed, others (like writing uninitialized
data into binfiles) hopefully can be ignored.
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 API documentation of these calls doesn't say so explicitly, but it
seems that a combination of g_object_unref()/g_free()/g_list_free() is
necessary. Rewrote the eptr smart pointer so that different deleter
functions can be selected as template parameters.
git-svn-id: https://zeitsenke.de/svn/SyncEvolution/trunk@521 15ad00c4-1369-45f4-8270-35d70d36bdcd
