GNOME Bugzilla – Bug 524964
e_book_backend_get_changes: valgrind report about use-after-free
Last modified: 2008-04-02 16:17:15 UTC
On 2008-03-28 and 2008-03-29 the nightly SyncEvolution testing of the then current Evolution trunk triggered valgrind reports for EDS and eventually a segfault of EDS: http://www.estamos.de/runtests/2008-03-29-10-00/head-evolution-trunk-minimal/6-evolution/ It still worked on 2008-03-27. The SVN update log for 2008-03-28 shows a change in e-dbhash.c: http://www.estamos.de/runtests/2008-03-28-10-00/head-evolution-trunk-minimal/1-evolutiontrunk/ + ** Fixes part of bug #518710 + + * configure.in: + Bump GLib requirement to 2.16.1. + + * libedataserver/e-dbhash.c: + Use GLib's new MD5 Checksum API. The MD5 utilities in + libedataserver are now deprecated. + + * libedataserver/md5-utils.c: + * libedataserver/md5-utils.h: + Deprecate these functions and reimplement them to be wrappers + for GLib's new MD5 Checksum API. ==13139== Thread 3: ==13139== Invalid read of size 1 ==13139== at 0x401F0B0: memcpy (mc_replace_strmem.c:406) ==13139== by 0x4438525: g_checksum_update (gchecksum.c:336) ==13139== by 0x4682EE0: e_dbhash_compare (e-dbhash.c:185) ==13139== by 0x508CDD0: e_book_backend_file_get_changes (e-book-backend-file.c:786) ==13139== by 0x4043322: e_book_backend_sync_get_changes (e-book-backend-sync.c:236) ==13139== by 0x4043D79: _e_book_backend_get_changes (e-book-backend-sync.c:456) ==13139== by 0x40453C4: e_book_backend_get_changes (e-book-backend.c:350) ==13139== by 0x4049F2F: impl_GNOME_Evolution_Addressbook_Book_getChanges (e-data-book.c:184) ==13139== by 0x40388EC: _ORBIT_skel_small_GNOME_Evolution_Addressbook_Book_getChanges (Evolution-DataServer-Addressbook-common.c:80) ==13139== by 0x43AC436: ORBit_POAObject_invoke (poa.c:1142) ==13139== by 0x43B2664: ORBit_OAObject_invoke (orbit-adaptor.c:338) ==13139== by 0x439F5D8: ORBit_small_invoke_adaptor (orbit-small.c:844) ==13139== by 0x43B02B9: ORBit_POAObject_handle_request (poa.c:1351) ==13139== by 0x43B095B: ORBit_POAObject_invoke_incoming_request (poa.c:1421) ==13139== by 0x439813A: giop_thread_queue_process (giop.c:771) ==13139== by 0x43989D7: giop_request_handler_thread (giop.c:481) ==13139== by 0x4479686: g_thread_pool_thread_proxy (gthreadpool.c:265) ==13139== by 0x4477AFE: g_thread_create_proxy (gthread.c:635) ==13139== by 0x452723F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==13139== by 0x45FF49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so) ==13139== Address 0x546604F is 3 bytes after a block of size 12 free'd ==13139== at 0x401D0CA: free (vg_replace_malloc.c:233) ==13139== by 0x4457900: g_free (gmem.c:187) ==13139== by 0x446CABB: g_slice_free1 (gslice.c:886) ==13139== by 0x4472679: g_string_free (gstring.c:479) ==13139== by 0x478711A: e_vcard_to_string (e-vcard.c:888) ==13139== by 0x508CDA9: e_book_backend_file_get_changes (e-book-backend-file.c:782) ==13139== by 0x4043322: e_book_backend_sync_get_changes (e-book-backend-sync.c:236) ==13139== by 0x4043D79: _e_book_backend_get_changes (e-book-backend-sync.c:456) ==13139== by 0x40453C4: e_book_backend_get_changes (e-book-backend.c:350) ==13139== by 0x4049F2F: impl_GNOME_Evolution_Addressbook_Book_getChanges (e-data-book.c:184) ==13139== by 0x40388EC: _ORBIT_skel_small_GNOME_Evolution_Addressbook_Book_getChanges (Evolution-DataServer-Addressbook-common.c:80) ==13139== by 0x43AC436: ORBit_POAObject_invoke (poa.c:1142) ==13139== by 0x43B2664: ORBit_OAObject_invoke (orbit-adaptor.c:338) ==13139== by 0x439F5D8: ORBit_small_invoke_adaptor (orbit-small.c:844) ==13139== by 0x43B02B9: ORBit_POAObject_handle_request (poa.c:1351) ==13139== by 0x43B095B: ORBit_POAObject_invoke_incoming_request (poa.c:1421) ==13139== by 0x439813A: giop_thread_queue_process (giop.c:771) ==13139== by 0x43989D7: giop_request_handler_thread (giop.c:481) ==13139== by 0x4479686: g_thread_pool_thread_proxy (gthreadpool.c:265) ==13139== by 0x4477AFE: g_thread_create_proxy (gthread.c:635) ==13139== by 0x452723F: start_thread (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==13139== by 0x45FF49D: clone (in /lib/tls/i686/cmov/libc-2.3.6.so)
Looks to me like e_dbhash_compare() got passed an invalid "compare_data" argument. The function just takes what it's given and hands it to GLib's Checksum API. I'll take a closer look at what the EBook file backend is doing.
e_vcard_to_string_vcard_30() in e-vcard.c is the most likely place where string corruption could be occurring. Patrick, is this crash reproducible? Looks like it was caused by some locally stored contact on the machine that originally crashed. If you could isolate the contact(s) causing the crash that would help a lot.
Yes, it is reproducible. I removed the database to test whether it really is caused by a corrupt database and the testIterateTwice test worked, but the next test then triggered the problem again. The crash seems to occur again as soon as the database is non-empty. To reproduce it: - remove databases - ./client-test Client::Source::vcard21::testSimpleInsert I'm afraid I don't have a stand-alone test case. You'll have to compile SyncEvolution (I guess the 0.7 release should do) and then test as described in the HACKING document.
When the nightly testing failed, I still only had glib 2.15.4 installed (as can be seen in the compile log). Later the minimum version check in configure was really bumped and since then compilation failed: r8598 | mbarnes | 2008-03-31 07:03:25 +0200 (Mo, 31 M� 2008) | 5 lines 2008-03-31 Matthew Barnes <mbarnes@redhat.com> * configure.in: Enforce the minimum GLib version (#525242). The comment quoted at the top of this issue report was from revision r8597, but it seems that configure.in wasn't really changed in that revision. Is it possible that the invalid memory read came from using a glib revision which had the necessary calls, but wasn't quite recent enough? I just installed glib 2.16.1, recompiled and reran the tests: now everything seems to work again.
It was fixed in the next revision: r8598 Hard to speculate what the problem might have been.
It seems to work again, so let's close this issue.