Re: libgcc double-free, backend won't die
От | Craig James |
---|---|
Тема | Re: libgcc double-free, backend won't die |
Дата | |
Msg-id | 475EA754.1090307@emolecules.com обсуждение исходный текст |
Ответ на | Re: libgcc double-free, backend won't die (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: libgcc double-free, backend won't die
|
Список | pgsql-performance |
Alvaro Herrera wrote: > Craig James wrote: >> This is driving me crazy. I have some Postgres C function extensions >> in a shared library. They've been working fine. I upgraded to Fedora >> Core 6 and gcc4, and now every time psql(1) disconnects from the >> server, the serverlog gets this message: >> >> *** glibc detected *** postgres: mydb mydb [local] idle: double free or corruption! (!prev): 0x08bfcde8 > > Do you have any Perl or Python functions or stuff like that? There is one Perl function, but it is never invoked during this test. I connect to Postgres, issue one "select myfunc()",and disconnect. >> Postgres 8.1.4 > > Please upgrade to 8.1.10 and try again. If it still fails we will be > much more interested in tracking it down. Good idea, but alas, no difference. I get the same "double free or corruption!" mesage. I compiled 8.1.10 from source andinstalled, then rebuilt all of my code from scratch and reinstalled the shared object. Same message as before. Here is my guess -- and this is just a guess. My functions use a third-party library which, of necessity, uses malloc/freein the ordinary way. I suspect that there's a bug in the Postgres palloc() code that's walking over memory thatregular malloc() allocates. The third-party library (OpenBabel) has been tested pretty thoroughly by me an others andhas no memory corruption problems. All malloc's are freed properly. Does that seem like a possibility? I can't figure out how to use ordinary tools like valgrind with a Postgres backend process to track this down. Thanks, Craig
В списке pgsql-performance по дате отправления: