Hello:
I was investigating the bug about "select cash_out(2)" crashing the
backend. I thought fixing was a simple matter of checking whether some
argument to the function was NULL or not.
I added a NULL checking, but it obviously is not triggered, because the
data received is not NULL, but a non-pointer integer that cannot be
dereferenced (doing so cause a segmentation fault).
It turns out to be a far more serious bug than that, and is not limited
to cash_out. All these functions have the same problem:
select proname from pg_proc where proargtypes=(select proargtypes from
pg_proc where proname='cash_in') and pronargs=1 and proisstrict='t'
order by proname;
With a few exceptions (the test(*) is long, as it requires one to wait for
the database to start after testing each function, but there are 16 out
of 107 functions(**) that cause backend crash).
The problem is related to PG_GETARG_POINTER in some way or another; the
dereferencing of a non-pointer integer makes the backend crash.
I, however, do not know how to fix this. I'm just pointing out this
problem so someone more knowledgeable than me with this pointer mess can
figure a way out.
(*) The test is
SELECT="select proname from pg_proc where proargtypes=''
and pronargs=1 and proisstrict='t' order by proname;"
for i in `psql regression -c "$SELECT"`; doecho $i >> func_testpsql regression -c "select $i(1);" >> func_test
2>&1sleep9
done
(**) Those are:
boolout
charout
cidout
date_out
int2out
int4out
nabstimeout
oidout
regclassout
regoperatorout
regoperout
regprocedureout
regprocout
regtypeout
reltimeout
smgrout
xidout
--
Alvaro Herrera (<alvherre[a]atentus.com>)
"The Gord often wonders why people threaten never to come back after they've
been told never to return" (www.actsofgord.com)