Re: [Evolution-hackers] valgrind error in evolution-addressbook-factory + libdb

[Patrick Ohly <patrick ohly gmx de>]

On Tue, 2012-03-06 at 14:33 +0100, Patrick Ohly wrote:
> Hello!
> 
> Checking the EDS daemons from master under valgrind found this:
> 
> # ==23596== Conditional jump or move depends on uninitialised value(s)
> # ==23596==    at 0x9A404E7: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x9A41CB1: __log_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x9A42F2D: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x9A43D9F: __log_put_record (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x9986B1B: __ham_add_el (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x997E1FD: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x99F5548: __dbc_iput (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x99F314F: __db_put (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x9A04EBA: __db_put_pp (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> # ==23596==    by 0x103CC953: do_create (e-book-backend-file.c:915)
> # ==23596==    by 0x103CCBFC: e_book_backend_file_create_contacts (e-book-backend-file.c:988)
> # ==23596==    by 0x4E4AC31: e_book_backend_sync_create_contacts (e-book-backend-sync.c:85)
> # ==23596==    by 0x4E4D3D7: book_backend_create_contacts (e-book-backend-sync.c:493)
> # ==23596==    by 0x4E4ED2A: e_book_backend_create_contacts (e-book-backend.c:465)
> # ==23596==    by 0x4E513D3: operation_thread (e-data-book.c:157)
> # ==23596==    by 0x83E9D07: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
> # ==23596==    by 0x83E77E5: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.3000.2)
> # ==23596==    by 0x8678B4F: start_thread (pthread_create.c:304)
> # ==23596==    by 0x896690C: clone (clone.S:112)
> # ==23596==  Uninitialised value was created by a stack allocation
> # ==23596==    at 0x994DB80: ??? (in /usr/lib/x86_64-linux-gnu/libdb-5.1.so)
> 
> That is with libdb 5.1.29-1 from Debian Testing, in 64 bit mode.
> 
> At first glance it doesn't look like EDS can be causing this. I don't
> have time to investigate by compiling libdb from source right now, but
> at least I wanted to point out that there might be a cause for random
> crashes.

It's not bad as I thought. Am I too pessimistic? ;-)

I've tracked it down and filed a bug against Debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662917

>From the report:
---------------------------------------------------------
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.

--------------------------------------------------------

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/