Good Morning,

Ubuntu has updated their version from libdbi 0.8.x to 0.9.0 and
in Debian unstable. One issue is that we have used _get_uint where
we now need to use _get_ulonglong to not generate a dbi error. The
other issues seem to be genuine memory issues with libdbi that lead
to a segfault in our testsuite.


invalid read in getTables

        [SCHEMA_EQUIPMENT] = "CREATE TABLE IF NOT EXISTS Equipment ("
                "id INTEGER PRIMARY KEY AUTOINCREMENT, "
                "created TIMESTAMP NOT NULL, "
                "updated TIMESTAMP NOT NULL, "
                "name TEXT, "
                "classmark1 NUMERIC, "
                "classmark2 BLOB, "
                "classmark3 BLOB, "
                "imei NUMERIC UNIQUE NOT NULL"
                ")",

        [SCHEMA_EQUIPMENT_WATCH] = "CREATE TABLE IF NOT EXISTS 
EquipmentWatch ("
                "id INTEGER PRIMARY KEY AUTOINCREMENT, "
                "created TIMESTAMP NOT NULL, "
                "updated TIMESTAMP NOT NULL, "
                "subscriber_id NUMERIC NOT NULL, "
                "equipment_id NUMERIC NOT NULL, "
                "UNIQUE (subscriber_id, equipment_id) "
                ")",


curr_table before getTables =  'SELECT Equipment.* FROM Equipment JOIN 
EquipmentWatch ON EquipmentWatch.equipment_id=Equipment.id WHERE 
EquipmentWatch.subscriber_id = 1 ORDER BY EquipmentWatch.updated DESC'
==17178== Invalid read of size 1
==17178==    at 0x40FA609: getTables (dbd_sqlite3.c:1462)
==17178==    by 0x40FA863: find_result_field_types.isra.0 
(dbd_sqlite3.c:868)
==17178==    by 0x40FB776: dbd_query (dbd_sqlite3.c:638)
==17178==    by 0x412B098: dbi_conn_queryf (in /usr/lib/i386-linux-
gnu/libdbi.so.1.1.0)
==17178==    by 0x804D7D9: get_equipment_by_subscr (db.c:549)
==17178==    by 0x804E3C9: db_get_subscriber (db.c:896)
==17178==    by 0x804F23A: db_create_subscriber (db.c:506)
==17178==    by 0x804B770: main (db_test.c:178)
==17178==  Address 0x64692e74 is not stack'd, malloc'd or (recently) free'd
==17178== 

Issuing the query shown in quotes triggers this out of bounds read. The
workaround I have is to make equ-join using a where clause.




==8810== Invalid read of size 1
==8810==    at 0x412FA54: _dbd_decode_binary (in /usr/lib/i386-linux-
gnu/libdbi.so.1.1.0)
==8810==    by 0x40F9C98: dbd_fetch_row (dbd_sqlite3.c:1741)
==8810==    by 0x412B7EE: dbi_result_seek_row (in /usr/lib/i386-linux-
gnu/libdbi.so.1.1.0)
==8810==    by 0x412BB59: dbi_result_next_row (in /usr/lib/i386-linux-
gnu/libdbi.so.1.1.0)
==8810==    by 0x804D6DB: get_equipment_by_subscr (db.c:558)
==8810==    by 0x804E2B9: db_get_subscriber (db.c:896)
==8810==    by 0x804FB1B: db_prepare (db.c:236)
==8810==    by 0x804C018: main (db_test.c:168)
==8810==  Address 0x44719e1 is 0 bytes after a block of size 1 alloc'd
==8810==    at 0x4028B4C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
x86-linux.so)
==8810==    by 0x41C1907: strdup (strdup.c:42)
==8810==    by 0x40F9C7B: dbd_fetch_row (dbd_sqlite3.c:1740)
==8810==    by 0x412B7EE: dbi_result_seek_row (in /usr/lib/i386-linux-
gnu/libdbi.so.1.1.0)
==8810==    by 0x412BB59: dbi_result_next_row (in /usr/lib/i386-linux-
gnu/libdbi.so.1.1.0)
==8810==    by 0x804D6DB: get_equipment_by_subscr (db.c:558)
==8810==    by 0x804E2B9: db_get_subscriber (db.c:896)
==8810==    by 0x804FB1B: db_prepare (db.c:236)
==8810==    by 0x804C018: main (db_test.c:168)
==8810== 

The tables after running the test includes:

sqlite> select * from Equipment;
1|2014-03-08 15:35:08|2014-03-08 15:35:28||51|||6666666666666666
3|2014-07-04 06:23:28|2014-07-04 06:23:28|||||1234567890
5|2014-07-04 06:23:28|2014-07-04 06:23:28|||||6543560920

The length of data->d_string at the time valgrind generates the warning
is 0. But not everytime it is 0 a warning will be generated.

Is this something that can be easily fixed?


holger



------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
libdbi-devel mailing list
libdbi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-devel

Reply via email to