From: Craig James <craig_james@emolecules.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: libgcc double-free, backend won't die
Date: Sun, 16 Dec 2007 11:03:11 -0800
Message-ID: <4765766F.9000902@emolecules.com> (raw)
In-Reply-To: <877ijeqzd9.fsf@oxford.xeocode.com>
References: <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>
<475EAB69.9@emolecules.com>
<20071211152838.GH4708@alvh.no-ip.org>
<475EB1B9.3000405@emolecules.com>
<20071211155703.GT31937@svr2.hagander.net>
<87r6htw4e7.fsf@oxford.xeocode.com>
<476564D6.7090702@mansionfamily.plus.com>
<27316.1197828101@sss.pgh.pa.us>
<877ijeqzd9.fsf@oxford.xeocode.com>
Gregory Stark wrote:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>
>> James Mansion <james@mansionfamily.plus.com> writes:
>>> Is there any particular reason not to ensure that any low-level
>>> threading support in libc is enabled right
>>> from the get-go, as a build-time option?
>> Yes.
>> 1) It's of no value to us
Who is "us"? Some of us would like to use the system for advanced scientific work, and scientific libraries are usually written in C++.
>> 2) On many platforms there is a nonzero performance penalty
I'm surprised you say this, given that you're usually the voice of reason when it comes to rejecting hypothetical statements in favor of tested facts. If building Postgres using thread-safe technology is really a performance burden, that could be easily verified. A "nonzero performance penalty", what does that mean, a 0.0001% slowdown? I find it hard to believe that the performance penalty of thread-safe version would even be measurable.
If nobody has the time to do such a test, or other priorities take precedence, that's understandable. But the results aren't in yet.
> And the only reason to do that would be to work around one bug in one small
> range of glibc versions. If you're going to use a multi-threaded library
> (which isn't very common since it's hard to do safely for all those other
> reasons) surely using a version of your OS without any thread related bugs is
> a better idea.
You're jumping ahead. This problem has not been accurately diagnosed yet. It could be that the pthreads issue is completely misleading everyone, and in fact there is a genuine memory corruption going on here. Or not. We don't know yet. I have made zero progress fixing this problem.
The "one small range of glibc versions" is a giveaway. I've seen this problem in FC3, 5, and 6 (I went through this series of upgrades all in one week trying to fix this problem). With each version, I recompiled Postgres and OpenBabel from scratch. I'm going to try FC7 next since it's now the only "official" supported version, but I don't believe glibc is the problem.
Andrew Dalke, a regular contributor to the OpenBabel forum, suggests another problem: It could be a result of linking the wrong libraries together. The gcc/ld system has a byzantine set of rules and hacks that if I understand Andrew's posting) select different versions of the same library depending on what it thinks you might need. It's possible that the wrong version of some system library is getting linked in.
Craig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig_james@emolecules.com, stark@enterprisedb.com, tgl@sss.pgh.pa.us
Subject: Re: libgcc double-free, backend won't die
In-Reply-To: <4765766F.9000902@emolecules.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox