Noah Misch wrote:
> 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.
Did we conclude any of these were useful?
http://archives.postgresql.org/pgsql-hackers/2011-03/msg00856.php
I know there were concerns about some of them in the thread.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +
