Re: Buffer overruns with the Electric Fence debugging library - Mailing list pgsql-hackers
From | Maurice Gittens |
---|---|
Subject | Re: Buffer overruns with the Electric Fence debugging library |
Date | |
Msg-id | 199803181550.QAA22596@david.gits.nl Whole thread Raw |
List | pgsql-hackers |
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 justbefore 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 "\001h���fo\t\b,o\207@�\217\207@\003") at execQual.c:1576 #3 0x80989aa in ExecProject (projInfo=0x40894fe8, isDone=0xbfffd653 "\001h���fo\t\b,o\207@�\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.
pgsql-hackers by date: