memory-related bugs
Noah Misch <noah@leadboat.com>
From: Noah Misch <noah@leadboat.com>
To: pgsql-hackers@postgresql.org
Date: 2011-03-12T13:32:24Z
Lists: pgsql-hackers
Attachments
- mem1v1-memcpy-overlap.patch (text/plain) patch
- mem2v1-analyze-overread.patch (text/plain) patch
- mem3v1-sjis-offbyone.patch (text/plain) patch
A suitably-instrumented run of "make installcheck-world" under valgrind turned up a handful of memory-related bugs: * memcpy()/strncpy() between overlapping regions uniqueentry() and dispell_lexize() both deduplicate an array by iteratively copying elements downward to occlude the duplicates. Before finding a first duplicate, these functions call memcpy() with identical arguments. Similarly, resolve_polymorphic_tupdesc() calls TupleDescInitEntry() with an attributeName pointing directly into the TupleDesc's name bytes, causing the latter to call strncpy() with identical arguments. The attached mem1v1-memcpy-overlap.patch fixes these sites by checking for equal pointers before the affected call. For TupleDescInitEntry(), I considered instead having resolve_polymorphic_tupdesc() pstrdup() the value. * read past the end of a Form_pg_type in examine_attribute() examine_attribute() copies a Form_pg_type naively. Since the nullable columns at the end of the structure are not present in memory, the memcpy() reads eight bytes past the end of the source allocation. mem2v1-analyze-overread.patch updates this code to match how we address the same issue for Form_pg_attribute. * off-by-one error in shift_jis_20042euc_jis_2004() This function grabs two bytes at a time, even when only one byte remains; this makes it read past the end of the input. mem3v1-sjis-offbyone.patch changes it to not do this and to report an error when the input ends in a byte that would start a two-byte sequence. Thanks, nm