memory corruption bug

If PostgreSQL failed to compile on your computer or you found a bug that
is likely to be specific to one platform then please fill out this form
and e-mail it to pgsql-ports(at)postgresql(dot)org(dot)

To report any other bug, fill out the form below and e-mail it to
pgsql-bugs(at)postgresql(dot)org(dot)

If you not only found the problem but solved it and generated a patch
then e-mail it to pgsql-patches(at)postgresql(dot)org instead. Please use the
command "diff -c" to generate the patch.

You may also enter a bug report at http://www.postgresql.org/ instead of
e-mail-ing this form.

============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================

Your name :Alan Stange
Your email address :stange(at)rentec(dot)com

System Configuration
---------------------
Architecture (example: Intel Pentium) : Sun UltraSparc IIICu

Operating System (example: Linux 2.4.18) : Solaris 9

PostgreSQL version (example: PostgreSQL-7.4.1): PostgreSQL-7.4.1

Compiler used (example: gcc 2.95.2) : Sun spro9.

Please enter a FULL description of your problem:
------------------------------------------------
There's memory corruption occuring causing the malloc routines to SIGBUS. This is typically caused
by a routine overwriting the end of malloc()'d memory causing corruption to the meta data used by malloc(),
free(), realloc(), etc.

We have this happen about once / day.

program terminated by signal BUS (invalid address alignment)
0xff043694: realfree+0x023c: ld [%o2 + 8], %o0
(dbx) where
=>[1] realfree(0x703b50, 0x782c0, 0x51, 0xff0bc000, 0x3c, 0x18cf08), at 0xff043694
[2] cleanfree(0x0, 0x9, 0xff0c26ec, 0x10018, 0x703b50, 0x0), at 0xff043d90
[3] _malloc_unlocked(0x20018, 0x79270, 0x0, 0xff0bc000, 0x0, 0x0), at 0xff042ebc
[4] malloc(0x20018, 0x20007, 0x0, 0x0, 0x0, 0x0), at 0xff042dac
[5] AllocSetAlloc(0x5cadf8, 0x20000, 0x0, 0x0, 0x0, 0x2000), at 0x24fdfc
[6] AllocSetRealloc(0x5cadf8, 0x604608, 0x20000, 0x604608, 0x2000, 0x604600), at 0x25053c
[7] enlargeStringInfo(0xffbfed48, 0x10473, 0x20000, 0x10474, 0x100, 0x1), at 0x10fb10
[8] pq_getmessage(0xffbfed48, 0x0, 0x0, 0x0, 0x2ff910, 0x604608), at 0x1181bc
[9] SocketBackend(0xffbfed48, 0x310400, 0x51, 0x30000, 0x3c, 0x18cf08), at 0x18d2bc
[10] PostgresMain(0x190400, 0x310c00, 0x1, 0x315000, 0x310c00, 0x1), at 0x19193c
[11] BackendFork(0x364b18, 0x356848, 0x2d043c, 0x2d044c, 0x310400, 0x319958), at 0x15b988
[12] BackendStartup(0x364b18, 0x7f7f7c00, 0x7f7f7c00, 0x3541d8, 0x6e0c3a8f, 0x349c00), at 0x15b170
[13] ServerLoop(0xc0, 0x310640, 0x364b18, 0x320e64, 0x1, 0x1), at 0x159814
[14] PostmasterMain(0x15b800, 0x15a500, 0xffffffff, 0x349000, 0x354000, 0x315000), at 0x159048
[15] main(0x1, 0x35608c, 0x3543d8, 0x3541d8, 0x0, 0x278), at 0x119bf4

These bugs are hard to fix. The actual corruption could have occured much earlier in the execution.

We had the same error with the gcc compilers as well. We're using the Sun compilers as the resulting
PG binaries are much faster.

Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
----------------------------------------------------------------------
Sadly, we have no reproducible test case right now.

If you know how this problem might be fixed, list the solution below:
---------------------------------------------------------------------

Typically one would use a tool like purify, bcheck, etc., to find the offending code.