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

From Alvaro Herrera
Subject Re: libgcc double-free, backend won't die
Date
Msg-id 20071211152838.GH4708@alvh.no-ip.org
Whole thread Raw
In response to Re: hardware and For PostgreSQL  (Ron St-Pierre <ron.pgsql@shaw.ca>)
Responses Re: libgcc double-free, backend won't die  (Craig James <craig_james@emolecules.com>)
Re: libgcc double-free, backend won't die  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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"

pgsql-performance by date:

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