Skip site navigation (1) Skip section navigation (2)

memory corruption bug

From: Alan Stange <stange(at)rentec(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: memory corruption bug
Date: 2004-03-30 15:40:22
Message-ID: 406994E6.mailxM3Z11IURX@monstert25 (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
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

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 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.


pgsql-bugs by date

Next:From: PostgreSQL Bugs ListDate: 2004-03-30 16:02:15
Subject: BUG #1121: JDBC AbstractJdbc2ResultSet.deleteRow()
Previous:From: rajesh kDate: 2004-03-30 06:56:21
Subject: psql: relocation error: psql: undefined

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group