Craig James <craig_james@emolecules.com> writes: > 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 Have you tried attaching to one of these processes with gdb to see where it ends up? Have you checked to see if the processes are becoming multi-threaded? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq

Craig James <craig_james@emolecules.com> writes: > GNU gdb Red Hat Linux (6.5-15.fc6rh) > Copyright (C) 2006 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > [snip - a bunch of symbol table stuff] Please show that stuff you snipped --- it might have some relevant information. The stack trace looks a bit like a threading problem... regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Craig James wrote: >> Can you elaborate? Are multithreaded libraries not allowed to be >> linked to Postgres? > Absolutely not. The problem is that you get into library-interaction bugs like the one discussed here: http://archives.postgresql.org/pgsql-general/2007-11/msg00580.php http://archives.postgresql.org/pgsql-general/2007-11/msg00610.php I suspect what you're seeing is the exact same problem on a different glibc internal mutex: the mutex is left uninitialized on the first trip through the code because the process is not multithreaded, and then after OpenBabel gets loaded the process becomes multithreaded, and then it starts trying to use the mutex :-(. Since the glibc boys considered the other problem to be their bug, they'd probably be interested in fixing this one too. Unfortunately, you picked a Fedora version that reached EOL last week. Update to FC7 or FC8, and if you still see the problem, file a bugzilla entry against glibc. But having said all that, that still only addresses the question of why the process hangs up during exit(). Why the double-free report is being made at all is less clear, but I kinda think that unexpected multithread behavior may be at bottom there too. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly

Craig James <craig_james@emolecules.com> writes: >> Please show that stuff you snipped --- it might have some relevant >> information. The stack trace looks a bit like a threading problem... > Using host libthread_db library "/lib/libthread_db.so.1". That's pretty suspicious, but not quite a smoking gun. Does "info threads" report more than 1 thread? > Reading symbols from /usr/lib/libstdc++.so.6...done. > Loaded symbols for /usr/lib/libstdc++.so.6 Hmm, I wonder whether *this* is the problem, rather than OpenBabel per se. Trying to use C++ inside the PG backend is another minefield of things that don't work. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

James Mansion <james@mansionfamily.plus.com> writes: > Is there any particular reason not to ensure that any low-level > threading support in libc is enabled right > from the get-go, as a build-time option? Yes. 1) It's of no value to us 2) On many platforms there is a nonzero performance penalty regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate