Re: 2nd try @NetBSD/2.0 Alpha - Mailing list pgsql-hackers

From Larry Rosenman
Subject Re: 2nd try @NetBSD/2.0 Alpha
Date
Msg-id 034801c5d42f$cf88d610$0e1993c0@lerctr.org
Whole thread Raw
In response to 2nd try @NetBSD/2.0 Alpha  ("Larry Rosenman" <ler@lerctr.org>)
List pgsql-hackers
Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
>> On Tue, Oct 18, 2005 at 04:04:42PM -0500, Larry Rosenman wrote:
>>> Upped the stack to 8Mb.  Now it dies in Plcheck.
> 
>> Wierd, it's dying in malloc() because the C library called kill()
>> from __libc_mutex_unlock().
> 
> I wonder if this is related to the "threaded libpython doesn't work"
> problem we've seen on some BSDen.  Does this platform have separate
> implementations of libc for threaded and unthreaded applications? 
> If so, and if libperl is trying to pull in a threaded libc along with
> itself, maybe this is the symptom you'd see.  It's reasonably
> probable that this is the first call to malloc() after libperl has
> been loaded into the backend ...   
> 
>             regards, tom lane

Doesn't appear to have a separate libc, HOWEVER, -lpthread may be screwing
us:

$ ldd perl
perl:        -lm.0 => /usr/lib/libm.so.0        -lcrypt.0 => /usr/lib/libcrypt.so.0        -lpthread.0 =>
/usr/lib/libpthread.so.0       -lperl =>
 
/usr/pkg/lib/perl5/5.8.0/alpha-netbsd-thread-multi/CORE/libperl.so        -lc.12 => /usr/lib/libc.so.12
$

I'm not the machines owner, but I can ask if we can get a NON-threaded PERL.



-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US



pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: A costing analysis tool
Next
From: Tom Lane
Date:
Subject: Re: 2nd try @NetBSD/2.0 Alpha