|
From: Holger F. <ho...@fr...> - 2014-07-15 06:57:28
|
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
|