Re: Buffer overruns with the Electric Fence debugging library

Hi,

As you requested I've included more information about the buffer overruns
detected by Electric Fence.

First (in postgres interactive mode) I enter the statement: "create database ipay;" Here stack dump of the situation just before the crash.
The memmove call gives buffer overrun.

177 data_length = VARSIZE(DatumGetPointer(value[i]));
178 memmove(data, DatumGetPointer(value[i]), data_length);
179 data += data_length;
180 break;
181 case sizeof(char):

Here is a stacktrace.

#0 DataFill (data=0x408c8fd4 "", tupleDesc=0x4088aff4, value=0x40896ff4,
nulls=0xbfffd5c0 " @", infomask=0x408c8fcc, bit=0x0) at heaptuple.c:178
#1 0x80600d0 in heap_formtuple (tupleDescriptor=0x4088aff4, value=0x40896ff4,
nulls=0xbfffd5c0 " @") at heaptuple.c:860
#2 0x8098940 in ExecTargetList (targetlist=0x4085aff4, nodomains=3,
targettype=0x4088aff4, values=0x40896ff4, econtext=0x40888fd4,
isDone=0xbfffd653 "\001hfo\t\b,o\207(at)\217\207@\003") at execQual.c:1576
#3 0x80989aa in ExecProject (projInfo=0x40894fe8,
isDone=0xbfffd653 "\001hfo\t\b,o\207(at)\217\207@\003") at execQual.c:1643
#4 0x809e260 in ExecResult (node=0x40876fb8) at nodeResult.c:163
#5 0x8096f66 in ExecProcNode (node=0x40876fb8, parent=0x40876fb8)
at execProcnode.c:249
#6 0x80965b4 in ExecutePlan (estate=0x4087afcc, plan=0x40876fb8,
parseTree=0x404fcfbc, operation=CMD_INSERT, numberTuples=0,
direction=ForwardScanDirection, printfunc=0x80615d0 <debugtup>)
at execMain.c:727
#7 0x80960f1 in ExecutorRun (queryDesc=0x40878ff0, estate=0x4087afcc,
feature=3, count=0) at execMain.c:236
#8 0x80e882b in ProcessQueryDesc (queryDesc=0x40878ff0) at pquery.c:332
#9 0x80e8896 in ProcessQuery (parsetree=0x404fcfbc, plan=0x40876fb8,
argv=0x0, typev=0x0, nargs=0, dest=Debug) at pquery.c:378
#10 0x80e755d in pg_exec_query_dest (
query_string=0xbfffd9d0 "insert into pg_database (datname, datdba, datpath)
values ('ipay', '500', 'ipay');", argv=0x0, typev=0x0, nargs=0, dest=Debug)

The query "select * from pg_shadow" crashes in the same function. However
this time the offending line is the one with the folling assigment.

195 *(int32 *) data = (att[i]->attbyval ?
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x805f524 in DataFill (data=0x40acafd4 "", tupleDesc=0x40ab2ff4,
value=0x40ac8fe0, nulls=0xbfffda78 " n \001\003\021\b",
infomask=0x40acafcc, bit=0x40acafcf "") at heaptuple.c:195
195 *(int32 *) data = (att[i]->attbyval ?
(gdb)

The stack trace for this one follows:

#0 DataFill (data=0x40acafd4 "", tupleDesc=0x40ab2ff4, value=0x40ac8fe0,
nulls=0xbfffda78 " n \001\003\021\b", infomask=0x40acafcc,
bit=0x40acafcf "") at heaptuple.c:195
#1 0x80600d0 in heap_formtuple (tupleDescriptor=0x40ab2ff4, value=0x40ac8fe0,
nulls=0xbfffda78 " n \001\003\021\b") at heaptuple.c:860
#2 0x8098940 in ExecTargetList (targetlist=0x40a84ff4, nodomains=8,
targettype=0x40ab2ff4, values=0x40ac8fe0, econtext=0x40aaefd4,
isDone=0xbfffdb0b "\001\034U+\t\b,\017"@a\t\b0U\206o\t\b,\017"@/@\001") at execQual.c:1576
#3 0x80989aa in ExecProject (projInfo=0x40ac6fe8,
isDone=0xbfffdb0b "\001\034U+\t\b,\017"@a\t\b0U\206o\t\b,\017"@/@\001") at execQual.c:1643
#4 0x8098a8f in ExecScan (node=0x40a80fb8, accessMtd=0x809e3b0 <SeqNext>)
at execScan.c:153
#5 0x809e42b in ExecSeqScan (node=0x40a80fb8) at nodeSeqscan.c:138
#6 0x8096f86 in ExecProcNode (node=0x40a80fb8, parent=0x40a80fb8)
at execProcnode.c:261
#7 0x80965b4 in ExecutePlan (estate=0x40aa4fcc, plan=0x40a80fb8,
parseTree=0x404a1fbc, operation=CMD_SELECT, numberTuples=0,
direction=ForwardScanDirection, printfunc=0x80615d0 <debugtup>)
at execMain.c:727
#8 0x80960f1 in ExecutorRun (queryDesc=0x40aa2ff0, estate=0x40aa4fcc,
feature=3, count=0) at execMain.c:236
#9 0x80e882b in ProcessQueryDesc (queryDesc=0x40aa2ff0) at pquery.c:332

The statement "create sequence test;" also gives a buffer overrun in the
function the call to memmove in DataFill.
So it might be that this happens often.

I hope this information is useful.

Thanks with regards from Maurice.