Re: libgcc double-free, backend won't die

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Craig James <craig_james(at)emolecules(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: libgcc double-free, backend won't die
Date: 2007-12-11 16:10:21
Message-ID: 15684.1197389421@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-12-11 16:19:27 Re: libgcc double-free, backend won't die
Previous Message Magnus Hagander 2007-12-11 15:57:03 Re: libgcc double-free, backend won't die