Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 854962E013E for ; Tue, 11 Dec 2007 12:10:28 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 29314-10 for ; Tue, 11 Dec 2007 12:10:24 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 7A9312E0079 for ; Tue, 11 Dec 2007 12:10:24 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lBBGALe2015685; Tue, 11 Dec 2007 11:10:21 -0500 (EST) To: Alvaro Herrera cc: Craig James , pgsql-performance@postgresql.org Subject: Re: libgcc double-free, backend won't die In-reply-to: <20071211152838.GH4708@alvh.no-ip.org> References: <4728FB3E.3070709@shaw.ca> <472978BE.9@hagander.net> <4729B1E9.2080306@gmail.com> <475E4133.5080009@emolecules.com> <20071211112128.GB4708@alvh.no-ip.org> <475EA754.1090307@emolecules.com> <20071211151416.GD10710@alvh.no-ip.org> <475EA9FD.9000706@emolecules.com> <20071211152010.GE10710@alvh.no-ip.org> <475EAB69.9@emolecules.com> <20071211152838.GH4708@alvh.no-ip.org> Comments: In-reply-to Alvaro Herrera message dated "Tue, 11 Dec 2007 12:28:39 -0300" Date: Tue, 11 Dec 2007 11:10:21 -0500 Message-ID: <15684.1197389421@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/143 X-Sequence-Number: 27959 Alvaro Herrera 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