Re: libgcc double-free, backend won't die - Mailing list pgsql-performance

From Tom Lane
Subject Re: libgcc double-free, backend won't die
Date
Msg-id 15684.1197389421@sss.pgh.pa.us
Whole thread Raw
In response to Re: libgcc double-free, backend won't die  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-performance
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

pgsql-performance by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: libgcc double-free, backend won't die
Next
From: Tom Lane
Date:
Subject: Re: libgcc double-free, backend won't die