Hi,
I have been looking at the functions in array_iterator.so. So far they have
proved to be very useful. However, I have manage to find a very serious bug
where the array_iterator() function causes some very bad stack corruption.
The stack corruption appears to be caused because pointer datums are not
checked for NULL before use.
The following SQL will quickly reproduce the problem (assumes contrib/array
stuff has been installed).
CREATE TABLE person (name VARCHAR(255));
CREATE TABLE family (name VARCHAR(255), members VARCHAR(255)[]);
INSERT INTO person VALUES ('bob');
INSERT INTO person VALUES ('bill');
INSERT INTO person VALUES ('jim');
INSERT INTO family VALUES ('Stooges',{"moe","curly","larry"}');
SELECT name FROM family WHERE members *= (SELECT name FROM person WHERE
name='jack');
A quick run through GDB shows that when the subselect does not return any
values the *= operator is called with a NULL value which eventually calls
the array_iterator() function with NULL value==0 which ultimately causes the
segv.
The following patch appears to fix the problem with all supported data types:
Yes, I did verify that int4 and Oid (which can have a 0 value) are not broken.
--- /tmp/postgresql-7.2.1.orig/contrib/array/array_iterator.c
+++ /tmp/postgresql-7.2.1/contrib/array/array_iterator.c
***************
*** 46,65 ****
--- 46,71 ----
char *p;
FmgrInfo finfo;
/* Sanity checks */
if (array == (ArrayType *) NULL)
{
/* elog(NOTICE, "array_iterator: array is null"); */
return (0);
}
+ if(value == 0)
+ {
+ /* elog(NOTICE, "array_iterator: value is null"); */
+ return (0);
+ }
+
/* detoast input if necessary */
array = DatumGetArrayTypeP(PointerGetDatum(array));
--
Matt Peterson
Sr. Software Engineer
Caldera, Inc
matt@caldera.com
