Message-ID: <475EABD6.2020200@emolecules.com>
Date: Tue, 11 Dec 2007 07:25:10 -0800
From: Craig James <craig_james@emolecules.com>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: libgcc double-free, backend won't die
References: <7EB0D6C0-48E2-4155-8559-9113D3BD2785@ketema.net>
	<4728CF7B.7040306@gmail.com> <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>
In-Reply-To: <20071211152010.GE10710@alvh.no-ip.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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?

Thanks,
Craig