Re: pfree() core dump in 7.2.3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Medi Montaseri <medi(dot)montaseri(at)intransa(dot)com>
Cc: pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: pfree() core dump in 7.2.3
Date: 2002-11-17 19:39:19
Message-ID: 6001.1037561959@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Medi Montaseri <medi(dot)montaseri(at)intransa(dot)com> writes:
> Has anyone experienced a pfree() related core dump in 7.2.3.
> Here is my gdb backtrace

> (gdb) bt
> #0 0x005dbb5c in pfree ()
> #1 0x004208c0 in heap_freetuple ()
> #2 0x004a8390 in acquire_sample_rows ()
> #3 0x004a75c8 in analyze_rel ()
> #4 0x0049f690 in vacuum ()
> #5 0x005585d8 in ProcessUtility ()
> #6 0x00553c78 in pg_exec_query_string ()

Hmm ... my first thought is something overrunning its memory allocation
and clobbering the mem manager's header for an adjacent palloc chunk.
However, it's impossible to guess what, with only this much info.

Could you rebuild the backend with --enable-debug --enable-cassert added
to the configure arguments, and reproduce the test case to get a more
informative backtrace?

Also, what platform is this on?

> FYI, I'm using the Async Query for my vacuum as shown below and I'm
> not doing the PQgetResult(), so I'm hoping that closing the connection will
> tear down the backend after finishing the vacuum...

I doubt this is affected by what you're doing on the client side.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Josh Berkus 2002-11-17 19:43:33 Press Release -- Just Waiting for Tom
Previous Message Tom Lane 2002-11-17 19:33:05 Re: [GENERAL] DECLARE CURSOR