Good Morning,
another memory corruption in 0.8.x (I didn't check if it applies
to 0.9) is in fetching binary row results when the actual size of
the string is 0. The comment in _dbd_decode_binary that not more
is written is wrong in the way that it reads (and then writes) to
out of bounds memory.
I modified the code like this and together with the other mail I
am down to just one memory corruption during the database migration.
case DBI_TYPE_BINARY:
data->d_string = strdup(raw);
if(strlen(data->d_string) == 0)
row->field_sizes[curfield] = 0;
else
row->field_sizes[curfield] = _dbd_decode_binary(data->d_string,
data->d_string);
break;
Valgrind:
0
==22527== Invalid read of size 1
==22527== at 0x4069D4E: _dbd_decode_binary (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x4037640: _get_row_data (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x403779A: dbd_fetch_row (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x4065304: dbi_result_seek_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x40655B4: dbi_result_next_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x8074951: db_prepare (db.c:304)
==22527== by 0x804CE52: main (bsc_hack.c:313)
==22527== Address 0x5170261 is 0 bytes after a block of size 1 alloc'd
==22527== at 0x4028A28: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
x86-linux.so)
==22527== by 0x41A98C7: strdup (strdup.c:42)
==22527== by 0x4037603: _get_row_data (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x403779A: dbd_fetch_row (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x4065304: dbi_result_seek_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x40655B4: dbi_result_next_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x8074951: db_prepare (db.c:304)
==22527== by 0x804CE52: main (bsc_hack.c:313)
==22527==
==22527== Invalid write of size 1
==22527== at 0x4069D45: _dbd_decode_binary (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x4037640: _get_row_data (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x403779A: dbd_fetch_row (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x4065304: dbi_result_seek_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x40655B4: dbi_result_next_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x8074951: db_prepare (db.c:304)
==22527== by 0x804CE52: main (bsc_hack.c:313)
==22527== Address 0x5170261 is 0 bytes after a block of size 1 alloc'd
==22527== at 0x4028A28: malloc (in /usr/lib/valgrind/vgpreload_memcheck-
x86-linux.so)
==22527== by 0x41A98C7: strdup (strdup.c:42)
==22527== by 0x4037603: _get_row_data (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x403779A: dbd_fetch_row (in /usr/lib/dbd/libdbdsqlite3.so)
==22527== by 0x4065304: dbi_result_seek_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x40655B4: dbi_result_next_row (in /usr/lib/libdbi.so.1.0.0)
==22527== by 0x8074951: db_prepare (db.c:304)
==22527== by 0x804CE52: main (bsc_hack.c:313)
==22527==
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Libdbi-drivers-devel mailing list
Libdbi-drivers-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libdbi-drivers-devel
