From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | valgrind errors |
Date: | 2004-04-21 18:49:54 |
Message-ID: | 1082573393.7010.27.camel@tokyo |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Valgrind'ing the postmaster yields a fair number of errors. A lot of
them are similar, such as the following:
==29929== Use of uninitialised value of size 4
==29929== at 0x80AFB80: XLogInsert (xlog.c:570)
==29929== by 0x808B0A6: heap_insert (heapam.c:1189)
==29929== by 0x808B19D: simple_heap_insert (heapam.c:1226)
==29929== by 0x80C28CC: AddNewAttributeTuples (heap.c:499)
==29929== by 0x80C2E36: heap_create_with_catalog (heap.c:787)
==29929== by 0x811F5AD: DefineRelation (tablecmds.c:252)
==29929== by 0x81DC9BF: ProcessUtility (utility.c:376)
==29929== by 0x81DB893: PortalRunUtility (pquery.c:780)
==29929== by 0x81DB9CE: PortalRunMulti (pquery.c:844)
==29929== by 0x81DB35C: PortalRun (pquery.c:501)
==29929== by 0x81D75E2: exec_simple_query (postgres.c:935)
==29929== by 0x81D9F95: PostgresMain (postgres.c:2984)
==29929==
==29929== Syscall param write(buf) contains uninitialised or
unaddressable byte(s)
==29929== at 0x3C1BAB28: write (in /usr/lib/debug/libc-2.3.2.so)
==29929== by 0x80B2124: XLogFlush (xlog.c:1416)
==29929== by 0x80AE348: RecordTransactionCommit (xact.c:549)
==29929== by 0x80AE82A: CommitTransaction (xact.c:930)
==29929== by 0x80AED8B: CommitTransactionCommand (xact.c:1242)
==29929== by 0x81D8934: finish_xact_command (postgres.c:1820)
==29929== by 0x81D762C: exec_simple_query (postgres.c:967)
==29929== by 0x81D9F95: PostgresMain (postgres.c:2984)
==29929== by 0x81A524E: BackendRun (postmaster.c:2662)
==29929== by 0x81A489E: BackendStartup (postmaster.c:2295)
==29929== by 0x81A2D0A: ServerLoop (postmaster.c:1165)
==29929== by 0x81A2773: PostmasterMain (postmaster.c:926)
==29929== Address 0x3C37BB57 is not stack'd, malloc'd or free'd
(These occur hundreds of times while valgrind'ing "make installcheck".)
The particular call chain that results in the XLogInsert() error is
variable; for example, here's another error report:
==29937== Use of uninitialised value of size 4
==29937== at 0x80AFA37: XLogInsert (xlog.c:555)
==29937== by 0x80978F3: _bt_split (nbtinsert.c:907)
==29937== by 0x80966A1: _bt_insertonpg (nbtinsert.c:504)
==29937== by 0x8095BB0: _bt_doinsert (nbtinsert.c:141)
==29937== by 0x809CC78: btinsert (nbtree.c:266)
==29937== by 0x826200E: OidFunctionCall6 (fmgr.c:1484)
==29937== by 0x80944FA: index_insert (indexam.c:226)
==29937== by 0x80C79E6: CatalogIndexInsert (indexing.c:121)
==29937== by 0x80C2A0B: AddNewAttributeTuples (heap.c:557)
==29937== by 0x80C2E36: heap_create_with_catalog (heap.c:787)
==29937== by 0x811F5AD: DefineRelation (tablecmds.c:252)
==29937== by 0x81DC9BF: ProcessUtility (utility.c:376)
Any thoughts on what could be causing these errors? (I looked into it,
but couldn't see anything that looked like an obvious culprit.)
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Matthew T. O'Connor | 2004-04-21 18:53:34 | Re: contrib vs. gborg/pgfoundry for replication solutions |
Previous Message | Bruce Momjian | 2004-04-21 18:17:36 | Re: contrib vs. gborg/pgfoundry for replication solutions |