pg.ddx.io pgsql-performance@postgresql.org mailing list archive
help / color / mirror / Atom feedlibgcc double-free, backend won't die
28+ messages / 8 participants
[nested] [flat]
* libgcc double-free, backend won't die
@ 2007-12-11 07:50 Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:07 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 28+ messages in thread
From: Craig James @ 2007-12-11 07:50 UTC (permalink / raw)
To: pgsql-performance
This is driving me crazy. I have some Postgres C function extensions in a shared library. They've been working fine. I upgraded to Fedora Core 6 and gcc4, and now every time psql(1) disconnects from the server, the serverlog gets this message:
*** glibc detected *** postgres: mydb mydb [local] idle: double free or corruption! (!prev): 0x08bfcde8
and the backend process won't die. Every single connection that executes one of my functions leaves an idle process, like this:
$ ps -ef | grep postgres
postgres 12938 12920 0 23:24 ? 00:00:00 postgres: mydb mydb [local] idle
This error only happens on disconnect. As long as I keep the connection open, I can
Worse, these zombie Postgres processes won't die, which means I can't shut down and restart Postgres unless I "kill -9" all of them, and I can't use this at all because I get zillions of these dead processes.
I've used valgrind on a test application that runs all of my functions outside of the Postgres environment, and not a single problem shows up even after hours of processing. I tried setting MALLOC_CHECK_ to various values, so that I could trap the abort() call using gdb, but once MALLOC_CHECK_ is set, the double-free error never occurs. (But malloc slows down too much this way.)
I even read through the documentation for C functions again, and carefully examined my code. Nothing is amiss, some of the functions are quite simple yet still exhibit this problem.
Anyone seen this before? It's driving me nuts.
Postgres 8.1.4
Linux kernel 2.6.22
gcc 4.1.1
Thanks,
Craig
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-11 11:21 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
1 sibling, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2007-12-11 11:21 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
Craig James wrote:
> This is driving me crazy. I have some Postgres C function extensions
> in a shared library. They've been working fine. I upgraded to Fedora
> Core 6 and gcc4, and now every time psql(1) disconnects from the
> server, the serverlog gets this message:
>
> *** glibc detected *** postgres: mydb mydb [local] idle: double free or corruption! (!prev): 0x08bfcde8
Do you have any Perl or Python functions or stuff like that?
> Postgres 8.1.4
Please upgrade to 8.1.10 and try again. If it still fails we will be
much more interested in tracking it down.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
Maybe there's lots of data loss but the records of data loss are also lost.
(Lincoln Yeoh)
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2007-12-11 15:05 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 28+ messages in thread
From: Craig James @ 2007-12-11 15:05 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
Alvaro Herrera wrote:
> Craig James wrote:
>> This is driving me crazy. I have some Postgres C function extensions
>> in a shared library. They've been working fine. I upgraded to Fedora
>> Core 6 and gcc4, and now every time psql(1) disconnects from the
>> server, the serverlog gets this message:
>>
>> *** glibc detected *** postgres: mydb mydb [local] idle: double free or corruption! (!prev): 0x08bfcde8
>
> Do you have any Perl or Python functions or stuff like that?
There is one Perl function, but it is never invoked during this test. I connect to Postgres, issue one "select myfunc()", and disconnect.
>> Postgres 8.1.4
>
> Please upgrade to 8.1.10 and try again. If it still fails we will be
> much more interested in tracking it down.
Good idea, but alas, no difference. I get the same "double free or corruption!" mesage. I compiled 8.1.10 from source and installed, then rebuilt all of my code from scratch and reinstalled the shared object. Same message as before.
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?
I can't figure out how to use ordinary tools like valgrind with a Postgres backend process to track this down.
Thanks,
Craig
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-11 15:14 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
0 siblings, 1 reply; 28+ messages in thread
From: Alvaro Herrera @ 2007-12-11 15:14 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
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.
--
Alvaro Herrera Valdivia, Chile ICBM: S 39º 49' 18.1", W 73º 13' 56.4"
"La vida es para el que se aventura"
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2007-12-11 15:17 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 1 reply; 28+ messages in thread
From: Craig James @ 2007-12-11 15:17 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: pgsql-performance
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.
Thanks,
Craig
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-11 15:20 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:25 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
0 siblings, 2 replies; 28+ messages in thread
From: Alvaro Herrera @ 2007-12-11 15:20 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
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.
--
Alvaro Herrera http://www.amazon.com/gp/registry/5ZYLFMCVHXC
"When the proper man does nothing (wu-wei),
his thought is felt ten thousand miles." (Lao Tse)
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2007-12-11 15:25 ` Craig James <craig_james@emolecules.com>
1 sibling, 0 replies; 28+ messages in thread
From: Craig James @ 2007-12-11 15:25 UTC (permalink / raw)
To: pgsql-performance
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2007-12-11 15:28 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 16:10 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 28+ messages in thread
From: Alvaro Herrera @ 2007-12-11 15:28 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: 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"
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2007-12-11 15:50 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
1 sibling, 1 reply; 28+ messages in thread
From: Craig James @ 2007-12-11 15:50 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: pgsql-performance
Alvaro Herrera wrote:
>>> ...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.
Ok, thanks, I'll work on recompiling OpenBabel without thread support.
Since I'm not a Postgres developer, perhaps one of the maintainers could update the Postgres manual. In chapter 32.9.6, it says,
"To be precise, a shared library needs to be created."
This should be amended to say,
"To be precise, a non-threaded, shared library needs to be created."
Cheers,
Craig
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-11 15:57 ` Magnus Hagander <magnus@hagander.net>
2007-12-11 16:25 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
0 siblings, 2 replies; 28+ messages in thread
From: Magnus Hagander @ 2007-12-11 15:57 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
> Alvaro Herrera wrote:
> >>>...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.
>
> Ok, thanks, I'll work on recompiling OpenBabel without thread support.
>
> Since I'm not a Postgres developer, perhaps one of the maintainers could
> update the Postgres manual. In chapter 32.9.6, it says,
>
> "To be precise, a shared library needs to be created."
>
> This should be amended to say,
>
> "To be precise, a non-threaded, shared library needs to be created."
>
Just before someone goes ahead and writes it (which is probably a good idea
in general), don't write it just like taht - because it's platform
dependent. On win32, you can certainly stick a threaded library to it -
which is good, because most (if not all) win32 libs are threaded... Now, if
they actually *use* threads explicitly things might break (but most likely
not from that specifically), but you can link with them without the
problem. I'm sure there are other platforms with similar situations.
//Magnus
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
@ 2007-12-11 16:25 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 16:35 ` Re: libgcc double-free, backend won't die Joshua D. Drake <jd@commandprompt.com>
2007-12-11 16:40 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
1 sibling, 2 replies; 28+ messages in thread
From: Tom Lane @ 2007-12-11 16:25 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
Magnus Hagander <magnus@hagander.net> writes:
> On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
>> Since I'm not a Postgres developer, perhaps one of the maintainers could
>> update the Postgres manual. In chapter 32.9.6, it says,
>>
>> "To be precise, a shared library needs to be created."
>>
>> This should be amended to say,
>>
>> "To be precise, a non-threaded, shared library needs to be created."
> Just before someone goes ahead and writes it (which is probably a good idea
> in general), don't write it just like taht - because it's platform
> dependent.
I can find no such text in our documentation at all, nor any reference
to OpenBabel. I think Craig must be looking at someone else's
documentation.
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 16:25 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-12-11 16:35 ` Joshua D. Drake <jd@commandprompt.com>
2007-12-11 17:06 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 28+ messages in thread
From: Joshua D. Drake @ 2007-12-11 16:35 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Magnus Hagander <magnus@hagander.net>; Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 11 Dec 2007 11:25:08 -0500
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
> >> Since I'm not a Postgres developer, perhaps one of the maintainers
> >> could update the Postgres manual. In chapter 32.9.6, it says,
> >>
> >> "To be precise, a shared library needs to be created."
> >>
> >> This should be amended to say,
> >>
> >> "To be precise, a non-threaded, shared library needs to be
> >> created."
>
> > Just before someone goes ahead and writes it (which is probably a
> > good idea in general), don't write it just like taht - because it's
> > platform dependent.
>
> I can find no such text in our documentation at all, nor any reference
> to OpenBabel. I think Craig must be looking at someone else's
> documentation.
It's actually 33.9.6 and it is in:
http://www.postgresql.org/docs/8.2/static/xfunc-c.html#DFUNC
He is looking directly at our documentation :)
Sincerely,
Joshua D. Drake
- --
The PostgreSQL Company: Since 1997, http://www.commandprompt.com/
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
SELECT 'Training', 'Consulting' FROM vendor WHERE name = 'CMD'
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHXrxJATb/zqfZUUQRAmSTAJwO0kdDovLB7kFGaPL9OPna3rm8ZwCfVaNo
XKtTfT7He9rNEvMBs5e+O94=
=qmOr
-----END PGP SIGNATURE-----
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 16:25 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 16:35 ` Re: libgcc double-free, backend won't die Joshua D. Drake <jd@commandprompt.com>
@ 2007-12-11 17:06 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 28+ messages in thread
From: Tom Lane @ 2007-12-11 17:06 UTC (permalink / raw)
To: Joshua D. Drake <jd@commandprompt.com>; +Cc: Magnus Hagander <magnus@hagander.net>; Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
"Joshua D. Drake" <jd@commandprompt.com> writes:
>> I can find no such text in our documentation at all, nor any reference
>> to OpenBabel. I think Craig must be looking at someone else's
>> documentation.
> It's actually 33.9.6 and it is in:
> http://www.postgresql.org/docs/8.2/static/xfunc-c.html#DFUNC
[ shrug... ] That documentation is not intended to address how to
configure OpenBabel. It's talking about setting up linker commands,
and "threaded" is not a relevant concept at that level.
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 16:25 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-12-11 16:40 ` Craig James <craig_james@emolecules.com>
1 sibling, 0 replies; 28+ messages in thread
From: Craig James @ 2007-12-11 16:40 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Magnus Hagander <magnus@hagander.net>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
>>> Since I'm not a Postgres developer, perhaps one of the maintainers could
>>> update the Postgres manual. In chapter 32.9.6, it says,
>>>
>>> "To be precise, a shared library needs to be created."
>>>
>>> This should be amended to say,
>>>
>>> "To be precise, a non-threaded, shared library needs to be created."
>
>> Just before someone goes ahead and writes it (which is probably a good idea
>> in general), don't write it just like taht - because it's platform
>> dependent.
>
> I can find no such text in our documentation at all, nor any reference
> to OpenBabel. I think Craig must be looking at someone else's
> documentation.
http://www.postgresql.org/docs/8.1/static/xfunc-c.html#DFUNChttp://www.postgresql.org/docs/8.1/stati...
Craig
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
@ 2007-12-11 17:02 ` Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
1 sibling, 1 reply; 28+ messages in thread
From: Gregory Stark @ 2007-12-11 17:02 UTC (permalink / raw)
To: Magnus Hagander <magnus@hagander.net>; +Cc: Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
"Magnus Hagander" <magnus@hagander.net> writes:
> On Tue, Dec 11, 2007 at 07:50:17AM -0800, Craig James wrote:
>
>> This should be amended to say,
>>
>> "To be precise, a non-threaded, shared library needs to be created."
>
> Just before someone goes ahead and writes it (which is probably a good idea
> in general), don't write it just like taht - because it's platform
> dependent. On win32, you can certainly stick a threaded library to it -
> which is good, because most (if not all) win32 libs are threaded... Now, if
> they actually *use* threads explicitly things might break (but most likely
> not from that specifically), but you can link with them without the
> problem. I'm sure there are other platforms with similar situations.
Even on Unix there's nothing theoretically wrong with loading a shared library
which uses threads. It's just that there are a whole lot of practical problems
which can crop up.
1) No Postgres function is guaranteed to be thread-safe so you better protect
against concurrent calls to Postgres API functions. Also Postgres functions
use longjmp which can restore the stack pointer to a value which may have
been set earlier, possibly by another thread which wouldn't work.
So you're pretty much restricted to calling Postgres API functions from the
main stack which means from the original thread Postgres loaded you with.
Then there's
2) Some OSes have bugs (notably glibc for a specific narrow set of versions)
and don't expect to have standard library functions called before
pthread_init() then called again after pthread_init(). If they expect the
system to be either "threaded" or "not threaded" then they may be surprised
to see that state change.
That just means you have to use a non-buggy version of your OS. Unfortunately
tracking down bugs in your OS to figure out what's causing them and whether
it's a particular known bug can be kind of tricky.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
@ 2007-12-16 17:48 ` James Mansion <james@mansionfamily.plus.com>
2007-12-16 18:01 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: James Mansion @ 2007-12-16 17:48 UTC (permalink / raw)
To: Gregory Stark <stark@enterprisedb.com>; +Cc: Magnus Hagander <magnus@hagander.net>; Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
Gregory Stark wrote:
> 1) No Postgres function is guaranteed to be thread-safe so you better protect
> against concurrent calls to Postgres API functions. Also Postgres functions
> use longjmp which can restore the stack pointer to a value which may have
> been set earlier, possibly by another thread which wouldn't work.
>
>
That's a whole different thing to saying that you can't use a threaded
subsystem under a Postgres
process.
> 2) Some OSes have bugs (notably glibc for a specific narrow set of versions)
> and don't expect to have standard library functions called before
> pthread_init() then called again after pthread_init(). If they expect the
> system to be either "threaded" or "not threaded" then they may be surprised
> to see that state change.
>
>
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? Does it do anything that's not
well defined in a threaded
process? Signal handling and atfork (and posix_ exec) are tyical areas
I guess. While this can potentially
make malloc slower, Postgres already wraps malloc so using a caching
thread-aware malloc
substitute such as nedmalloc should be no problem.
I don't see any issue with the setjmp usage - so long as only one thread
uses any internal API. Which
can be checked rather easily at runtime with low cost in a debug build.
> That just means you have to use a non-buggy version of your OS. Unfortunately
> tracking down bugs in your OS to figure out what's causing them and whether
> it's a particular known bug can be kind of tricky.
>
Is that really much of an issue an the current version of any major OS
though? Its reaonable to
limit the use of a threaded library (in particular, the runtimes for
most embeddable languages, or
libraries for RPC runtimes, etc) to 'modern' platforms that support
threads effectively. On
many such platforms these will already implicitly link libpthread anyway.
James
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
@ 2007-12-16 18:01 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-16 18:16 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 22:24 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
0 siblings, 2 replies; 28+ messages in thread
From: Tom Lane @ 2007-12-16 18:01 UTC (permalink / raw)
To: James Mansion <james@mansionfamily.plus.com>; +Cc: Gregory Stark <stark@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
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
2) On many platforms there is a nonzero performance penalty
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
2007-12-16 18:01 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-12-16 18:16 ` Gregory Stark <stark@enterprisedb.com>
2007-12-16 19:03 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
1 sibling, 1 reply; 28+ messages in thread
From: Gregory Stark @ 2007-12-16 18:16 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: James Mansion <james@mansionfamily.plus.com>; Magnus Hagander <magnus@hagander.net>; Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
"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
> 2) On many platforms there is a nonzero performance penalty
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.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Slony Replication support!
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
2007-12-16 18:01 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-16 18:16 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
@ 2007-12-16 19:03 ` Craig James <craig_james@emolecules.com>
2007-12-16 20:06 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
0 siblings, 1 reply; 28+ messages in thread
From: Craig James @ 2007-12-16 19:03 UTC (permalink / raw)
To: Gregory Stark <stark@enterprisedb.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-performance
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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
2007-12-16 18:01 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-16 18:16 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 19:03 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-16 20:06 ` Gregory Stark <stark@enterprisedb.com>
0 siblings, 0 replies; 28+ messages in thread
From: Gregory Stark @ 2007-12-16 20:06 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-performance
"Craig James" <craig_james@emolecules.com> writes:
> Gregory Stark wrote:
>
>> 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.
Well, no that would be you jumping ahead then... You proposed Postgres
changing the way it handles threaded libraries based on Tom's suggestion that
your problem was something like the glibc problem previously found. My comment
was based on the known glibc problem. From what you're saying it's far from
certain that the problem would be fixed by changing Postgres's behaviour in
the way you proposed.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's On-Demand Production Tuning
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
2007-12-16 18:01 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-12-16 22:24 ` James Mansion <james@mansionfamily.plus.com>
2007-12-17 08:52 ` Re: libgcc double-free, backend won't die Bruce Momjian <bruce@momjian.us>
1 sibling, 1 reply; 28+ messages in thread
From: James Mansion @ 2007-12-16 22:24 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Gregory Stark <stark@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
Tom Lane wrote:
> Yes.
>
> 1) It's of no value to us
>
> 2) On many platforms there is a nonzero performance penalty
>
>
I think you have your head in the ground, but its your perogative. *You*
might not care, but anyone wanting to use thread-aware libraries (and I'm
*not* talking about threading in any Postgres code) will certainly value
it if
they can do so with some stability.
There's a clear benefit to being able to use such code. I suggested a
build option but you reject it out of hand. And in doing so, you also
lock out
the benefits that you *could* have as well, in future.. It seems religious,
which is unfortunate.
Are you suggesting that the performance penalty, apart from the
malloc performance (which is easily dealt with) is *material*?
An extra indirection in access to errno will hurt so much? Non-zero I can
accept, but clinging to 'non-zero' religiously isn't smart, especially
if its a
build-time choice.
We'll clearly move to multiple cores, and the clock speed enhancements will
slow (at best). In many cases, the number of available cores will
exceed the
number of instantaneously active connections. Don't you want to be able
to use all the horsepower?
Certainly on the sort of systems I work in my day job (big derivative
trading
systems) its the norm that the cache hit rate on Sybase is well over
99%, and
such systems are typically CPU bound. Parallelism matters, and will matter
more and more in future.
So, an ability to start incrementally adding parallel operation of some
actions
(whether scanning or updating indices or pushing data to the peer) is
valuable,
as is the ability to use threaded libraries - and the (potential?)
ability to use
embedded languages and more advanced libraries in Postgres procs is one
of the
advantages of the system itself. (I'd like to discount the use of a
runtime in a
seperate process - the latency is a problem for row triggers and functions)
James
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Re: libgcc double-free, backend won't die Magnus Hagander <magnus@hagander.net>
2007-12-11 17:02 ` Re: libgcc double-free, backend won't die Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
2007-12-16 18:01 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-16 22:24 ` Re: libgcc double-free, backend won't die James Mansion <james@mansionfamily.plus.com>
@ 2007-12-17 08:52 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 28+ messages in thread
From: Bruce Momjian @ 2007-12-17 08:52 UTC (permalink / raw)
To: James Mansion <james@mansionfamily.plus.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Gregory Stark <stark@enterprisedb.com>; Magnus Hagander <magnus@hagander.net>; Craig James <craig_james@emolecules.com>; Alvaro Herrera <alvherre@alvh.no-ip.org>; pgsql-performance
James Mansion wrote:
> I think you have your head in the ground, but its your perogative.
> *You* might not care, but anyone wanting to use thread-aware libraries
> (and I'm *not* talking about threading in any Postgres code) will
> certainly value it if they can do so with some stability.
I suggest you find out the cause of your problem and then we can do more
research. Talking about us changing the Postgres behavior from the
report of one user who doesn't even have the full details isn't
productive.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:28 ` Re: libgcc double-free, backend won't die Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2007-12-11 16:10 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 28+ messages in thread
From: Tom Lane @ 2007-12-11 16:10 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: Craig James <craig_james@emolecules.com>; pgsql-performance
Alvaro Herrera <alvherre@alvh.no-ip.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
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-11 15:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:12 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
1 sibling, 1 reply; 28+ messages in thread
From: Tom Lane @ 2007-12-11 15:07 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
Craig James <craig_james@emolecules.com> writes:
> This is driving me crazy. I have some Postgres C function extensions in a shared library. They've been working fine. I upgraded to Fedora Core 6 and gcc4, and now every time psql(1) disconnects from the server, the serverlog gets this message:
> *** glibc detected *** postgres: mydb mydb [local] idle: double free or corruption! (!prev): 0x08bfcde8
Have you tried attaching to one of these processes with gdb to see where
it ends up? Have you checked to see if the processes are becoming
multi-threaded?
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:07 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-12-11 15:12 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:43 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Craig James @ 2007-12-11 15:12 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance
Tom Lane wrote:
> Craig James <craig_james@emolecules.com> writes:
>> This is driving me crazy. I have some Postgres C function extensions in a shared library. They've been working fine. I upgraded to Fedora Core 6 and gcc4, and now every time psql(1) disconnects from the server, the serverlog gets this message:
>> *** glibc detected *** postgres: mydb mydb [local] idle: double free or corruption! (!prev): 0x08bfcde8
>
> Have you tried attaching to one of these processes with gdb to see where
> it ends up? Have you checked to see if the processes are becoming
> multi-threaded?
>
> regards, tom lane
>
# ps -ef | grep postgres
postgres 31362 1 0 06:53 ? 00:00:00 /usr/local/pgsql/bin/postmaster -D /postgres/main
postgres 31364 31362 0 06:53 ? 00:00:00 postgres: writer process
postgres 31365 31362 0 06:53 ? 00:00:00 postgres: stats buffer process
postgres 31366 31365 0 06:53 ? 00:00:00 postgres: stats collector process
postgres 31442 31362 0 06:54 ? 00:00:00 postgres: craig_test craig_test [local] idle
root 31518 31500 0 07:06 pts/6 00:00:00 grep postgres
# gdb -p 31442
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
[snip - a bunch of symbol table stuff]
0x00110402 in __kernel_vsyscall ()
(gdb) bt
#0 0x00110402 in __kernel_vsyscall ()
#1 0x0082fb8e in __lll_mutex_lock_wait () from /lib/libc.so.6
#2 0x007bfce8 in _L_lock_14096 () from /lib/libc.so.6
#3 0x007befa4 in free () from /lib/libc.so.6
#4 0x00744f93 in _dl_map_object_deps () from /lib/ld-linux.so.2
#5 0x0074989d in dl_open_worker () from /lib/ld-linux.so.2
#6 0x00745c36 in _dl_catch_error () from /lib/ld-linux.so.2
#7 0x00749222 in _dl_open () from /lib/ld-linux.so.2
#8 0x00858712 in do_dlopen () from /lib/libc.so.6
#9 0x00745c36 in _dl_catch_error () from /lib/ld-linux.so.2
#10 0x008588c5 in __libc_dlopen_mode () from /lib/libc.so.6
#11 0x00836139 in init () from /lib/libc.so.6
#12 0x008362d3 in backtrace () from /lib/libc.so.6
#13 0x007b3e11 in __libc_message () from /lib/libc.so.6
#14 0x007bba96 in _int_free () from /lib/libc.so.6
#15 0x007befb0 in free () from /lib/libc.so.6
#16 0x001f943a in DeleteByteCode (node=0x890ff4) at chains.cpp:477
#17 0x00780859 in exit () from /lib/libc.so.6
#18 0x081a6064 in proc_exit ()
#19 0x081b5b9d in PostgresMain ()
#20 0x0818e34b in ServerLoop ()
#21 0x0818f1de in PostmasterMain ()
#22 0x08152369 in main ()
(gdb)
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:07 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:12 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-11 15:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:53 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
0 siblings, 1 reply; 28+ messages in thread
From: Tom Lane @ 2007-12-11 15:43 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
Craig James <craig_james@emolecules.com> writes:
> GNU gdb Red Hat Linux (6.5-15.fc6rh)
> Copyright (C) 2006 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> [snip - a bunch of symbol table stuff]
Please show that stuff you snipped --- it might have some relevant
information. The stack trace looks a bit like a threading problem...
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:07 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:12 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:43 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
@ 2007-12-11 15:53 ` Craig James <craig_james@emolecules.com>
2007-12-11 16:19 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 28+ messages in thread
From: Craig James @ 2007-12-11 15:53 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-performance
Tom Lane wrote:
> Craig James <craig_james@emolecules.com> writes:
>> GNU gdb Red Hat Linux (6.5-15.fc6rh)
>> Copyright (C) 2006 Free Software Foundation, Inc.
>> GDB is free software, covered by the GNU General Public License, and you are
>> welcome to change it and/or distribute copies of it under certain conditions.
>
>> [snip - a bunch of symbol table stuff]
>
> Please show that stuff you snipped --- it might have some relevant
> information. The stack trace looks a bit like a threading problem...
# gdb -p 31442
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
Attaching to process 31442
Reading symbols from /usr/local/pgsql/bin/postgres...(no debugging symbols found)...done.
Using host libthread_db library "/lib/libthread_db.so.1".
Reading symbols from /usr/lib/libz.so.1...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libreadline.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libreadline.so.5
Reading symbols from /lib/libtermcap.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libtermcap.so.2
Reading symbols from /lib/libcrypt.so.1...
(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /lib/libresolv.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libm.so.6...
(no debugging symbols found)...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
Reading symbols from /usr/local/pgsql/lib/libchmoogle.so...done.
Loaded symbols for /usr/local/pgsql/lib/libchmoogle.so
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/jaguarformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/jaguarformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/libopenbabel.so.2...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/libopenbabel.so.2
Reading symbols from /usr/lib/libstdc++.so.6...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fastaformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fastaformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cansmilesformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cansmilesformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/APIInterface.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/APIInterface.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mmodformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mmodformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/molreportformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/molreportformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fhformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fhformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemkinformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemkinformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mmcifformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mmcifformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/thermoformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/thermoformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/carformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/carformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/ghemicalformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/ghemicalformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/turbomoleformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/turbomoleformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/xmlformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/xmlformat.so
Reading symbols from /usr/lib/libxml2.so.2...done.
Loaded symbols for /usr/lib/libxml2.so.2
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/rxnformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/rxnformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/reportformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/reportformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/acrformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/acrformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/nwchemformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/nwchemformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/hinformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/hinformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/bgfformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/bgfformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/shelxformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/shelxformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/yasaraformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/yasaraformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/viewmolformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/viewmolformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mdlformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mdlformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/CSRformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/CSRformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cacaoformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cacaoformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gaussformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gaussformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/titleformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/titleformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gamessformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gamessformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/zindoformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/zindoformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fingerprintformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fingerprintformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/balstformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/balstformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cssrformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cssrformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cdxmlformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cdxmlformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/crkformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/crkformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/xedformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/xedformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemdrawcdxformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemdrawcdxformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cmlformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cmlformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mpdformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mpdformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/amberformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/amberformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/smilesformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/smilesformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemtoolformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemtoolformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pubchem.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pubchem.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fchkformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fchkformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/qchemformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/qchemformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mopacformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mopacformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/PQSformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/PQSformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fastsearchformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/fastsearchformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/freefracformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/freefracformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chem3dformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chem3dformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/inchiformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/inchiformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cccformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cccformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mpqcformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mpqcformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/copyformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/copyformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cifformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cifformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/unichemformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/unichemformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/boxformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/boxformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mol2format.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/mol2format.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/tinkerformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/tinkerformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/featformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/featformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/alchemyformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/alchemyformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pngformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pngformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pcmodelformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pcmodelformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/dmolformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/dmolformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gausscubeformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gausscubeformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/povrayformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/povrayformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/xyzformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/xyzformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cacheformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/cacheformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemdrawctformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/chemdrawctformat.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gromos96format.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/gromos96format.so
Reading symbols from /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pdbformat.so...done.
Loaded symbols for /usr/local/openbabel-inst/openbabel-dev-2-1-x/lib/openbabel/pdbformat.so
0x00110402 in __kernel_vsyscall ()
(gdb) bt
#0 0x00110402 in __kernel_vsyscall ()
#1 0x0082fb8e in __lll_mutex_lock_wait () from /lib/libc.so.6
#2 0x007bfce8 in _L_lock_14096 () from /lib/libc.so.6
#3 0x007befa4 in free () from /lib/libc.so.6
#4 0x00744f93 in _dl_map_object_deps () from /lib/ld-linux.so.2
#5 0x0074989d in dl_open_worker () from /lib/ld-linux.so.2
#6 0x00745c36 in _dl_catch_error () from /lib/ld-linux.so.2
#7 0x00749222 in _dl_open () from /lib/ld-linux.so.2
#8 0x00858712 in do_dlopen () from /lib/libc.so.6
#9 0x00745c36 in _dl_catch_error () from /lib/ld-linux.so.2
#10 0x008588c5 in __libc_dlopen_mode () from /lib/libc.so.6
#11 0x00836139 in init () from /lib/libc.so.6
#12 0x008362d3 in backtrace () from /lib/libc.so.6
#13 0x007b3e11 in __libc_message () from /lib/libc.so.6
#14 0x007bba96 in _int_free () from /lib/libc.so.6
#15 0x007befb0 in free () from /lib/libc.so.6
#16 0x001f943a in DeleteByteCode (node=0x890ff4) at chains.cpp:477
#17 0x00780859 in exit () from /lib/libc.so.6
#18 0x081a6064 in proc_exit ()
#19 0x081b5b9d in PostgresMain ()
#20 0x0818e34b in ServerLoop ()
#21 0x0818f1de in PostmasterMain ()
#22 0x08152369 in main ()
(gdb)
^ permalink raw reply [nested|flat] 28+ messages in thread
* Re: libgcc double-free, backend won't die
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:07 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:12 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 15:43 ` Re: libgcc double-free, backend won't die Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:53 ` Re: libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
@ 2007-12-11 16:19 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 28+ messages in thread
From: Tom Lane @ 2007-12-11 16:19 UTC (permalink / raw)
To: Craig James <craig_james@emolecules.com>; +Cc: pgsql-performance
Craig James <craig_james@emolecules.com> writes:
>> Please show that stuff you snipped --- it might have some relevant
>> information. The stack trace looks a bit like a threading problem...
> Using host libthread_db library "/lib/libthread_db.so.1".
That's pretty suspicious, but not quite a smoking gun. Does "info
threads" report more than 1 thread?
> Reading symbols from /usr/lib/libstdc++.so.6...done.
> Loaded symbols for /usr/lib/libstdc++.so.6
Hmm, I wonder whether *this* is the problem, rather than OpenBabel
per se. Trying to use C++ inside the PG backend is another minefield
of things that don't work.
regards, tom lane
^ permalink raw reply [nested|flat] 28+ messages in thread
end of thread, other threads:[~2007-12-17 08:52 UTC | newest]
Thread overview: 28+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2007-12-11 07:50 libgcc double-free, backend won't die Craig James <craig_james@emolecules.com>
2007-12-11 11:21 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:05 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:14 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:17 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:20 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:25 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:28 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2007-12-11 15:50 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:57 ` Magnus Hagander <magnus@hagander.net>
2007-12-11 16:25 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 16:35 ` Joshua D. Drake <jd@commandprompt.com>
2007-12-11 17:06 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 16:40 ` Craig James <craig_james@emolecules.com>
2007-12-11 17:02 ` Gregory Stark <stark@enterprisedb.com>
2007-12-16 17:48 ` James Mansion <james@mansionfamily.plus.com>
2007-12-16 18:01 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-16 18:16 ` Gregory Stark <stark@enterprisedb.com>
2007-12-16 19:03 ` Craig James <craig_james@emolecules.com>
2007-12-16 20:06 ` Gregory Stark <stark@enterprisedb.com>
2007-12-16 22:24 ` James Mansion <james@mansionfamily.plus.com>
2007-12-17 08:52 ` Bruce Momjian <bruce@momjian.us>
2007-12-11 16:10 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:07 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:12 ` Craig James <craig_james@emolecules.com>
2007-12-11 15:43 ` Tom Lane <tgl@sss.pgh.pa.us>
2007-12-11 15:53 ` Craig James <craig_james@emolecules.com>
2007-12-11 16:19 ` Tom Lane <tgl@sss.pgh.pa.us>
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