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

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Craig James <craig_james(at)emolecules(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: libgcc double-free, backend won't die
Date: 2007-12-11 15:28:39
Message-ID: 20071211152838.GH4708@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Craig James wrote:
> Alvaro Herrera wrote:
>> Craig James wrote:
>>> Alvaro Herrera wrote:
>>>> Craig James wrote:
>>>>
>>>>> Here is my guess -- and this is just a guess. My functions use a
>>>>> third-party library which, of necessity, uses malloc/free in the
>>>>> ordinary way. I suspect that there's a bug in the Postgres palloc()
>>>>> code that's walking over memory that regular malloc() allocates. The
>>>>> third-party library (OpenBabel) has been tested pretty thoroughly by
>>>>> me an others and has no memory corruption problems. All malloc's are
>>>>> freed properly. Does that seem like a possibility?
>>>> Not really. palloc uses malloc underneath.
>>> But some Postgres code could be walking off the end of a malloc'ed
>>> block, even if palloc() is allocating and deallocating correctly.
>>> Which is why I was hoping to use valgrind to see what's going on.
>>
>> I very much doubt it. Since you've now shown that OpenBabel is
>> multithreaded, then that's a much more likely cause.
>
> Can you elaborate? Are multithreaded libraries not allowed to be
> linked to Postgres?

Absolutely not.

--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"La gente vulgar solo piensa en pasar el tiempo;
el que tiene talento, en aprovecharlo"

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-12-11 15:43:06 Re: libgcc double-free, backend won't die
Previous Message Craig James 2007-12-11 15:25:10 Re: libgcc double-free, backend won't die