pfree() core dump in 7.2.3

pfree() core dump in 7.2.3

Post by Medi Montase » Mon, 18 Nov 2002 06:53:40



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);

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

 
 
 

pfree() core dump in 7.2.3

Post by Tom La » Tue, 19 Nov 2002 04:39:24



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

Quote:> 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

---------------------------(end of broadcast)---------------------------


 
 
 

pfree() core dump in 7.2.3

Post by Medi Montase » Wed, 20 Nov 2002 04:40:27


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



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

---------------------------(end of broadcast)---------------------------

 
 
 

1. Core dump on PG 7.1.3

Thanks ... I'll do that in the wee hours of tomorrow morning and let you
know how it turns out ...

Thanks for the quick responses ...

-Dave

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command

2. Deleting Access Table ?

3. Troubleshooting cored dumps

4. Help ! Visual c++ compile error message !!!!!!!!!!!!!!!!!

5. postgres core dump PS

6. Q: Getting the definition of a SP on the server

7. Fix for possible pg_dump core dump

8. OLAP products

9. core dump on a prepare statement

10. initdb failing - core dump

11. Pro*C program core dump when linked with libclntsh

12. initdb failing - core dumped

13. postgres core dump