Thread: pfree() core dump in 7.2.3
Has anyone experienced a pfree() related core dump in 7.2.3.
Here is my gdb backtrace
0 0x005dbb5c in pfree ()
(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 ()
#7 0x00555850 in PostgresMain ()
#8 0x00524660 in DoBackend ()
#9 0x00523d08 in BackendStartup ()
#10 0x00521c18 in ServerLoop ()
#11 0x005211c8 in PostmasterMain ()
#12 0x004df3d8 in main ()
#13 0x2ae34928 in __libc_start_main () from /lib/libc.so.6
(gdb)
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...
if ( ! PQsendQuery( Conn, SQL.c_str() ) )
{
cout << __FUNCTION__
<< " : Failed to execute Async vacuum ["
<< PQerrorMessage(Conn) << "]\n";
PQfinish(Conn);
return status;
}
PQflush(Conn);
PQfinish(Conn);
Medi Montaseri <medi.montaseri@intransa.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
I'm using 7.2.3 on an SMP MIPS Linux kernel 2.4.17, libc 2.2.3 My organization has mocked around with the kernel (memory manager, etc) and as such I'm leaving much room for "its our bad" ....I'll work on having another target to compile with --enable-debug and cassert... Again, I need to make sure that my Async Query is not amplifying the problem.... So currently I need to keep a table within a range (low-water and hi-water mark). So I have implemented a "Async and Interleaved Purge". When I hit the hi-water-mark, I do the Async Purge of 2000 rows. At mid-water mark, I do the vacuum-ing by sending an async query. Again I close connections and move on.....hoping that the backend will thru away anything it had to say after completing the task... Thanks for the help... Tom Lane wrote: >Medi Montaseri <medi.montaseri@intransa.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 > >